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1. 


INTRODUCTION 


1.1  PURPOSE  OF  THE  PROJECT 

One  goal  of  the  Smart  Weapon  Operability  Enhancement  (SWOE)  Program  under 
the  Balanced  Technology  Initiative  (BTI)  is  to  enhance  the  operational  capabilities  of 
future  smart  weapons  through  more  comprehensive  consideration  of  the  environment.  A 
key  element  of  the  SWOE  program  is  a  planned  sensor  evaluation  and  test  facility  for  mil¬ 
limeter  wave  (MMW)  and  infrared  (IR)  sensors.  Sensor  studies  will  be  carried  out  using 
both  actual  field  data  and  simulated  data.  The  purpose  of  the  Cloud  Scene  Model  Develop¬ 
ment  project  is  to  meet  the  latter  objective  by  simulating  realistic  cloud  fields  for  use  in  ra¬ 
diometric  sensor  evaluation  studies  as  well  as  scene  visualization.  Two  major  efforts  of  the 
Cloud  Scene  Simulation  project  are  model  software  development  and  applied  research. 

1 .2  OVERVIEW  OF  PROJECT  TASKS 

Model  software  development  tasks  include  the  design,  implementation,  integra¬ 
tion,  testing,  documentation  and  delivery  of  two  interim  models  and  a  final  cloud  model. 
Applied  research  tasks  include  the  analysis  of  cloud  data  (specifically  liquid  water  densi¬ 
ty)  and  the  comparison  of  various  synthetic  field  generation  techniques.  Results  from 
these  analyses  are  used  in  model  development  with  the  goal  of  producing  physically  and 
visually  realistic  cloud  fields  with  computational  efficiency. 

The  six  technical  tasks  are  outlined  below.  Further  detail  on  the  tasks  completed  to 
date  (Tasks  1  through  4)  follows  in  Sections  2  and  3  of  this  report.  Future  tasks  are  dis¬ 
cussed  in  Section  4. 

TASK  1  MODEL  DESIGN 

Analyze  SWOE  requirements.  Design  a  stochastic  cloud  scene  simulation 
model  based  on  observed  cloud  morphology  and  atmospheric  physics. 
Specify  algorithms,  data  structures,  data  flows  and  software  architecture. 

TASK  2  MODEL  VERSION  1.0  (The  Prototype  Model) 

Rapidly  implement,  test  and  deliver  a  prototype  cloud  model  based  on  the 
Boehm  sawtooth  wave  technique  for  generation  of  random  fields  (Refs.  1 
and  2).  Model  stratiform  cloud  type  only.  Test  software  before  delivery. 
Prepare  a  User’s  Guide. 


1 


TASK  3  STUDIES  AND  ANALYSES 


Survey  recent  scientific  literature  to  identify  prior  investigations  of  the 
spatial  and  temporal  variability  of  cloud  water  over  geographical  regions 
of  interest.  If  necessary,  locate,  obtain  and  analyze  empirical  cloud  data. 
Compare  alternate  field  generation  algorithms  including  the  Boehm  saw¬ 
tooth  wave,  fractional  Brownian  motion  (Ref.  3)  and  the  turning  bands 
(Ref.  4)  techniques.  Determine  model  parameters  which  will  result  in 
shapes  and  water  distributions  characteristic  of  stratiform,  cumuliform 
and  cirriform  cloud  types. 

TASK  4  MODEL  VERSION  2.0  (The  Interim  Model) 

Refine  the  prototype  model  based  on  the  results  of  Task  3.  Add  the  capabil¬ 
ity  to  generate  cirriform  cloud  types.  Test  prior  to  delivery.  Prepare  a 
User’s  Guide. 

TASK  5  SWOE  COMPATIBILITY 

Evaluate  selected  SWOE  cloud  history  databases  and  radiative  transfer 
models  for  compatibility  with  the  cloud  scene  simulation  model. 

TASK  6  MODEL  VERSION  3.0  (The  Enhanced  Model) 

Refine  the  interim  model  using  the  knowledge  gained  in  previous  tasks. 
Develop  a  cumuliform  cloud  model  and  add  temporal  dimension.  Test  soft¬ 
ware  prior  to  delivery.  Prepare  a  User’s  Guide. 
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2. 


MODEL  DESIGN  AND  IMPLEMENTATION 


The  development  of  the  Cloud  Scene  Simulation  model  is  an  iterative  process,  con¬ 
sisting  of  requirements  analysis,  model  design,  implementation,  testing  and  documenta¬ 
tion.  In  this  section  we  discuss  the  development  of  the  prototype  and  interim  models.  We 
also  describe  two  supporting  software  packages;  the  shadow  post-processor  which  com¬ 
putes  the  ground  shadow  for  a  given  location,  time  of  day  and  cloud  field,  and  the  visualiza¬ 
tion  post-processor  which  reduces  the  cloud  model  output  to  colored  polygonal  surfaces  for 
use  in  scene  visualization  at  the  Engineer  Topographic  Laboratories. 


2.1  MODEL  REQUIREMENTS  AND  DESIGN 

Evaluation  of  SWOE  requirements  was  the  early  focus  of  the  Cloud  Scene  Simula¬ 
tion  project,  followed  by  model  design.  In  discussions  with  other  SWOE  participants,  in¬ 
cluding  personnel  at  the  Phillips  Laboratory,  a  set  of  requirements  was  formulated.  Those 
requirements  are  outlined  in  the  left-hand  column  of  Table  1.  The  right-hand  column  con¬ 
tains  the  model  design  decisions  responding  to  each  of  the  requirements. 

One  can  imagine  simulating  cloud  fields  by  many  possible  methods:  approximating 
specific  cloud  types  by  simple  geometric  shapes,  using  a  physics-based  numerical  weather 
model,  generating  fine  structure  cloud  fields  within  coarse  resolution  nephanalysis-type 
data,  or  using  one  of  various  stochastic  field  generation  techniques.  Based  on  an  analysis 
of  the  first  four  requirements  listed  in  Table  1,  we  chose  to  base  the  cloud  model  on  stochas¬ 
tic  field  generation  techniques. 

These  techniques  can  provide  an  excellent  tool  for  the  generation  of  complex  fields. 
Such  fields  are  more  representative  of  the  complexity  found  in  natural  cloud  fields  than 
simple  geometric  representations  (e.g.,  approximating  a  stratus  layer  with  a  flat  plane). 
This  is  important  for  simulating  sensor  response  to  complex  cloud  edges,  holes  and  other 
density  variations.  All  of  the  stochastic  algorithms  we  considered  for  this  project  allow  the 
user  to  control  the  complexity  in  a  field  by  varying  parameters  in  the  algorithm. 

Given  the  range  of  domain  sizes  and  resolutions  required  by  the  SWOE  program, 
relatively  efficient  stochastic  models  are  preferable  to  numerically  intensive  physical 
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Table  1  Overall  SWOE  Requirements 


SWOE  MODEL  REQUIREMENTS 

DESIGN  DECISIONS 

Produce  realistic  spatial  and  temporal  distribu¬ 
tions  of  cloud  water  (for  stratiform,  cirriform  and 
cumuliform  types)  in  the  absence  of  real  data. 

Treat  the  complex  structures  of  clouds  for  realism 
in  radiometric  sensor  computations  (e.g.,  cloud 
edge  effects). 

Use  stochastic  algorithm. 

Generate  multiple  scenes  given  identical  meteo¬ 
rological  input  for  sensitivity  studies. 

Produce  cloud  fields  in  a  computationally  efficient 
manner. 

Generate  high  resolution  cloud  fields  where  nec¬ 
essary  for  use  in  radiometric  computations  and 
visualization  (accommodate  low  resolution  clouds 
on  the  horizon). 

Incorporate  variable  resolution  data  grid. 

Allow  for  a  wide  range  of  ground  domain  sizes 
and  resolutions. 

Use  variable  resolution  grid  to  economize  on 
memory  storage  requirements  and  simulate 
scenes  on  scales  of  10-100  km. 

Provide  capability  to  generate  scenes  for  a  vari¬ 
ety  of  sensor  applications  (e.g.,  top  down,  skim¬ 
mer,  air-to-air,  etc.). 

Generate  fields  that  can  be  viewed  from  all 
angles.  Include  capability  to  produce  scenes 
large  enough  to  have  clouds  stretching  off  to  the 
horizon. 

Produce  cloud  scenes  representative  of  any  user- 
specified  location  and  historical  time. 

Accept  historical  meteorological  data  on  model 
input. 

Generate  model  output  in  a  form  that  can  be  used 
for  radiometric  sensor  studies  (both  MMW  and  IR 
applications). 

Produce  liquid  water  density  fields  as  output. 

Integrate  model  with  other  SWOE  simulation 
models. 

Design  model  with  replaceable  interface  module. 
Write  all  software  in  standard  FORTRAN  77. 
Design  model  to  be  highly  modular. 

Provide  polygonalized  cloud  scenes  to  ETL  for 
visualization. 

implement  polygon  generation  method  with  the 
capability  to  simulate  colored  cloud  scenes  (for 
additional  realism). 

12  Generate  cloud  shadow  map  for  input  to  energy 
balance  computations. 


Provide  a  cloud  shadow  post-processor. 


models.  Additionally,  stochastic  fields  are  ideally  suited  to  multiple  simulation^  and  sensi¬ 
tivity  studies.  Given  identical  meteorological  input,  countless  scenes  can  be  generated  (all 
satisfying  the  same  scene  requirements)  by  varying  a  random  number  seed  used  to  initial¬ 
ize  the  stochastic  model.  Such  sensitivity  studies  will  be  an  integral  part  of  radiometric 
sensor  evaluation  studies. 

Requirements  5  through  7  listed  in  Table  1  concern  the  size,  shape  and  resolution  of 
the  simulated  cloud  domain.  Py  employing  a  variable  resolution  data  structure,  we  can 
produce  the  high  resolution  necessary  over  the  domain  of  interest  (approximately  5-10  me¬ 
ters),  as  well  as  lower  resolution  away  from  the  area  (e.g.,  off  to  the  horizon  as  required  for 
the  cloud  shadow  program).  This  type  of  variable  resolution  geometry  is  not  only  computa¬ 
tionally  efficient,  but  it  mimics  the  way  we  view  clouds:  higher  resolution  overhead, 
stretching  off  to  lower  resolutions  at  the  horizon.  A  variable  resolution  data  structure  was 
not  implemented  in  either  the  prototype  or  interim  model,  but  will  be  a  part  of  the  en¬ 
hanced  model. 

A  further  requirement  within  the  SWOE  program  is  that  the  cloud  model  simulate 
fields  representative  (at  least  in  a  statistical  sense)  of  specific  locations  and  past  times.  It 
is  important  to  note  that  the  model  is  not  required  to  simulate  the  exact  location  of  clouds 
and  distribution  of  liquid  water  on  any  given  day,  rather,  the  requirement  is  to  simulate 
cloud  fields  that  have  representative  mean,  variance  and  spatial  distribution  of  cloud  wa¬ 
ter  for  the  area  and  time  of  interest.  Three  locations  have  been  proposed  as  demonstration 
sites  including  one  each  in  California,  Michigan  and  Germany.  The  cloud  model  will  use 
historical  meteorological  data  from  these  locations  as  input  (e.g.,  temperature  and  humid¬ 
ity  soundings,  cloud  base  and  top  heights,  etc.). 

The  ninth  and  tenth  requirements  listed  in  Table  1  concern  integrating  the  cloud 
model  with  other  SWOE  models.  First,  cloud  model  output  fields  will  be  used  as  input  to 
radiometric  sensor  studies.  An  evaluation  of  several  radiative  transfer  models  resulted  in 
the  conclusion  that  liquid  water  density  data  is  sufficient  information  from  which  to  com¬ 
pute  radiative  properties  of  the  cloud  field  (Ref.  5).  Second,  we  use  standard  FORTRAN  77 
and  a  highly  modular  model  design  to  simplify  integration. 

Finally,  the  last  two  requirements  concern  post-processing  of  the  gridded  liquid  wa¬ 
ter  content  fields.  We  have  designed  the  visualization  and  cloud  shadow  post-processors  to 
satisfy  these  requirements.  Both  are  discussed  later  in  this  report.  Similar  tables  of 
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requirements  and  design  decisions  specific  to  the  prototype  and  interim  models  follow  in 
Sections  2.2.1  and  2.3.1,  respectively. 


2.2  THE  PROTOTYPE  MODEL  (VERSION  1.0) 

TASC  rapidly  developed,  tested  and  delivered  a  prototype  cloud  scene  model  based 
on  the  Boehm  sawtooth  wave  (BSW)  and  fractional  Brownian  motion  (FBM)  stochastic 
field  generation  models.  Both  low  and  middle  cloud  layers  can  be  generated  with  this  mod¬ 
el. 

Two  versions  of  the  prototype  model  (differing  only  in  their  memory  requirements) 
were  delivered:  a  high  resolution  version  intended  to  run  on  a  workstation  or  mainframe 
computer,  and  a  low  resolution  version  designed  for  a  PC.  A  description  of  the  prototype 
model  is  provided  in  this  section.  Additional  details  about  the  prototype  model,  including 
software  organization,  model  input  and  output  and  installation,  can  be  found  in  the  User’s 
Guide  (Ref.  6).  Improvements  to  the  prototype  model  have  been  included  in  the  second  ver¬ 
sion  of  the  cloud  model  (the  interim  model)  and  are  described  in  Section  2.3. 

2.2.1  Prototype  Model  Requirements  and  Design 

Requirements  specific  to  the  development  of  the  prototype  model  are  described 
briefly  in  Table  2.  Many  of  the  design  decisions  listed  in  the  table  were  direct  results  of  the 
time  constraints  inherent  in  the  development  of  a  rapid  prototype  model.  For  example,  be¬ 
cause  of  TASC’s  previous  experience  with  the  technique,  we  chose  the  Boehm  sawtooth 
wave  algorithm  to  generate  stochastic  fields.  By  using  the  sawtooth  wave  model  as  a  base, 
we  were  able  to  develop  a  cloud  model  quickly.  Likewise,  due  to  time  constraints  and  the 
fact  that  scenes  were  to  be  generated  at  specific  locations  only  (e.g.,  Hunter-Liggett,  Cali¬ 
fornia),  we  decided  to  limit  the  prototype  model  capability  to  a  small  number  of  cloud  types 
(stratus  (St),  stratocumulus  (Sc),  altostratus  (As)  and  altocumulus  (Ac))  and  cloud  layers 
(low  and  middle). 

Due  to  the  rapid  development  cycle,  we  chose  to  simulate  cloud  fields  in  three  di¬ 
mensions  only.  Temporal  evolution  will  be  included  in  the  enhanced  model.  A  regular  3-d 
Cartesian  grid  was  used  throughout  the  prototype  and  interim  models  as  well.  This  re¬ 
sulted  not  only  in  more  rapid  development  time,  but  in  a  more  portable  model  for  early  us¬ 
ers  of  the  model. 
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Table  2  Requirements  and  Design  for  Prototype  Model 


■ 

PROTOTYPE  MODEL  REQUIREMENTS 

DESIGN  DECISIONS 

Use  BSW  stochastic  field  generation  model. 

Limit  to  stratiform  cloud  types:  St,  Sc,  As,  Ac. 

1 

Develop  quickly  for  feedback  from  other  SWOE 
participants. 

Limit  to  two  cloud  layers:  low  and  middle. 

Simulate  cloud  fields  in  three  dimensions  only.  Do 
not  simulate  temporal  dimension. 

Use  a  regular  Cartesian  grid. 

2 

Use  standard  and  portable  software  for  easy  inte¬ 
gration  with  other  SWOE  models. 

Write  software  in  standard  FORTRAN  77.  Rely  on 
no  system  functions  or  computer-specific  exten¬ 
sions.  Write  output  files  as  ASCII  files  for  easy 
portability.  Use  regular  3-d  grid  geometry. 

o 

Create  stand-alone  program. 

Build  interface  routine  which  communicates  with 
the  user.  Acquire  input  data  from  user  by  question 
and  answer.  Write  field  to  output  file  for  further 
processing. 

Generate  temperature  profile  from  user-specified 
surface  temperature  and  known  wet  and  dry  adia¬ 
batic  lapse  rates.  User  specifies  cloud  type,  base 
and  top  heights. 

0 

Develop  model  without  complete  knowledge  of 
liquid  water  content  distributions. 

Assume  Gaussian  distribution  of  water  with  stan¬ 
dard  deviation  equal  to  10%  of  the  mean. 

5 

Simulate  cloud  water  fields  representative  of  spe¬ 
cific  cloud  types  and  environmental  conditions. 

Use  mean  liquid  water  content  data  (for  given 
cloud  type  and  temperature)  from  Feddes'  AWS 
report  (Ref.  7). 

6 

Simulate  realistic  3-d  structure  of  cloud  types. 

Use  multi-step  technique  to  produce  overall  field. 
Use  BSW  model  to  generate  horizontal  structure. 
Build  vertical  structure  based  on  dome-like 
shape.  Generate  3-d  internal  structure  indepen¬ 
dently  with  separate  model  parameters. 

The  cloud  model  is  only  one  element  of  the  larger  SWOE  program.  With  this  in 
mind,  we  carefully  designed  a  robust  and  easily-removable  driver  for  the  model.  All  input 
parameters  and  output  data  are  passed  through  this  interface.  Thus  the  cloud  model  acts 
as  a  “black  box”  which  accepts  various  parameters  as  input  and  generates  gridded  cloud 
data  as  output.  Input  parameters  include  information  about  the  environmental  conditions 
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at  a  specific  location  and  time  (see  Section  2.2.2  for  a  list  of  input  parameters).  Sounding 
data  are  not  used  in  the  prototype  and  interim  models  (though  they  will  be  used  in  the  en¬ 
hanced  model).  We  therefore  assumed  a  temperature  profile  based  on  standard  dry  and 
wet  lapse  rates  outside  and  inside  the  cloud  region,  respectively. 

To  satisfy  the  fifth  requirement  listed  in  Table  2,  to  simulate  cloud  water  fields  rep¬ 
resentative  of  specific  cloud  types  and  conditions,  we  used  a  method  described  in  Ref.  7 
that  defines  the  mean  liquid  water  content  for  any  vertical  level  within  a  cloud  layer  as  a 
function  of  cloud  type,  temperature  and  vertical  position  within  the  layer.  In  both  the  pro¬ 
totype  and  interim  models  we  assumed  that  liquid  water  could  be  modeled  as  having  a 
Gaussian  distribution  with  mean  computed  as  in  Ref.  7,  and  with  constant  coefficient  of 
variation  (we  use  10%,  as  discussed  in  Section  2.2.2).  Assumptions  about  means  and  dis¬ 
tributional  forms  will  be  tested  later  in  the  Studies  and  Analyses  task  of  this  project 
(Task  3). 

Most  importantly,  in  response  to  the  last  requirement  listed  in  Table  2,  it  was  neces¬ 
sary  to  produce  three-dimensional  stochastic  fields  that  reproduce  the  spatial  characteris¬ 
tics  of  the  four  previously-mentioned  cloud  types.  These  cloud  types  (St,  Sc,  As,  Ac)  are 
known  for  their  relatively  flat  cloud  bases,  characteristic  of  the  isotropic  horizontal  tem¬ 
perature  distributions  within  which  they  frequently  form.  They  also  have  generally 
smooth,  undulating  upper  cloud  surfaces.  Through  TASC’s  experience  with  working  with 
various  stochastic  field  algorithms,  it  was  thought  that  no  single  three-dimensional 
algorithm  could  replicate  the  specific  horizontal  and  vertical  structure  of  these  clouds. 
Therefore  the  prototype  model  was  designed  as  a  multi-stage  process.  The  two-dimension¬ 
al  Boehm  sawtooth  wave  algorithm  was  used  to  generate  the  distribution  of  clouds  in  the 
horizontal.  A  fractal  model  was  used  to  generate  the  vertical  cloud  structure.  A  three- 
dimensional  field  generation  technique  was  used  to  generate  the  internal  liquid  water 
density  variations.  This  combination  provided  a  starting  point  for  model  development. 

2.2.2  Mqjor  Prototype  Model  Procedures 

An  outline  of  the  major  procedures  in  the  prototype  model  is  provided  here.  Each 
procedure  is  described  in  more  detail  in  the  following  subsections. 

•  Acquire  model  input  parameters 

•  Generate  horizontal  cloud  field 
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•  Generate  upper  cloud  surface 

•  Generate  lower  cloud  surface 

•  Generate  internal  cloud  structure 

•  Write  three-dimensional  cloud  field  to  output  file. 


Acquire  Model  Input  Parameters — Various  parameters  are  required  as  input  to  the 
prototype  model.  The  user  specifies  cloud  base  and  top  heights  (for  each  layer)  along  with 
horizontal  range  to  define  the  overall  cloud  region.  Fractional  coverage  and  cloud  type  are 
also  requested  for  each  layer.  Surface  temperature  and  elevation  are  used  to  compute  a 
temperature  profile  for  the  liquid  water  density  computations.  The  remaining  input  pa¬ 
rameters  include  grid  resolution,  random  number  seed  and  output  filename. 


Generate  Horizontal  Cloud  Field  —  The  BSW  model,  developed  at  the  Phillips 
Laboratory,  is  used  to  generate  the  initial  distribution  of  cloud  elements  in  the  horizontal 
plane.  First  a  two-dimensional  Gaussian  field  is  generated.  A  threshold  value  is  then 
applied  to  the  field  to  define  a  binary  cloud/no  cloud  distribution.  Later,  upper  and  lower 
surfaces  are  built  around  cloud  elements  to  create  a  three-dimensional  cloud  scene.  In  this 
section  we  provide  an  overview  of  the  procedure  used  to  generate  a  horizontal  cloud  distri¬ 
bution.  We  begin  with  a  brief  review  of  the  BSW  model.  A  more  thorough  description  of  the 
model  can  be  found  in  Ref.  1. 

The  BSW  model  generates  a  Gaussian  perturbation  field.  The  field  is  generated  by 
superimposing  multiple  “sawtooth  waves”  onto  the  horizontal  domain,  summing  the 
heights  of  the  sawtooth  waves  at  each  grid  point  in  the  domain  and  normalizing  the  result¬ 
ing  height.  The  sawtooth  waves  are  stationary  waves  with  specified  wavelength  (for  our 
application,  wavelength  is  a  function  of  cloud  type).  The  wave  height  varies  linearly  from  0 
to  1  across  the  length  of  the  wave.  A  cross-sectional  view  of  the  sawtooth  wave  is  shown  in 
Fig.  1.  Multiple  (N)  waves  with  random  orientation  and  phase  (as  measured  from  the  cen¬ 
ter  of  the  horizontal  domain)  are  overlaid  across  the  two-dimensional  space.  The  three  pa¬ 
rameters  defining  the  sawtooth  waves  and  their  geometric  relationship  to  the  horizontal 
cloud  domain  are  shown  in  Fig.  2. 
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Figure  1  Cross-Sectional  View  of  Sawtooth  Wave  (From  Ref.  1) 


Figure  2  Formation  of  Sawtooth  Waves  in  Horizontal  Domain  (From  Ref.  1) 
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At  each  grid  point  the  N  individual  wave  heights  are  summed.  For  large  N,  the  Cen¬ 
tral  Limit  Theorem  can  be  applied,  and  a  normal  deviate  (ND)  for  each  gridpoint  is  calcu¬ 
lated  as  follows: 


ND(x,y) 


'  N 

Hn  (x,y) 

.n=  1 


N 

2 


(2.2-1) 


where 

•  N  is  the  number  of  waves 

•  Hn  is  the  height  of  a  single  wave  at  point  (x,y) 

•  x,y  are  the  coordinates  of  a  grid  point  on  the  horizontal  plane. 


Once  the  two-dimensional  perturbation  field  has  been  generated,  a  candidate 
threshold  value  (dependent  on  the  fractional  cloud  cover  of  the  particular  cloud  layer)  is 
calculated  and  applied  to  the  field.  Values  falling  above  the  threshold  are  deemed  to  be 
cloud,  those  below  are  clear.  The  threshold  value  is  calculated  by  converting  the  desired 
fractional  cloud  cover  (cumulative  probability)  to  a  normal  deviate  by  the  following  equa¬ 
tion  (Ref.  8)  where  p  =  1  -  %cloud  cover,  a  =  2.30753,  b  =  0.27061,  c  =  0.99229  and  d  = 
0.04481: 

p  >  0.5  p  <  =  0.5 

k  =  1  k  =  -1 

t  =  /Zn[l/(1  -  p)2]  t  =  y /n[l/p2] 

THRESH  =  k  *  [  t  -  (a  +  bt)  /  ( 1  +  ct  +  dt2)  ] .  (2.2-2) 


The  candidate  threshold  may  be  slightly  off  due  to  two  factors:  we  use  a  discrete 
(though  relatively  large)  number  of  waves  to  create  the  field,  and  we  sample  the  field  at  a 
limited  number  of  grid  points.  This  results  in  small  deviations  from  the  specified  cloud/ 
clear  amounts  after  applying  the  recommended  threshold.  For  the  prototype  model,  an  it¬ 
erative  process  was  developed  to  slightly  vary  the  threshold  until  the  correct  fractional 
coverage  was  produced.  When  simulating  cloud  climatology  (one  of  the  main  uses  of  the 
BSW  model),  slight  deviations  from  the  exact  fractional  coverage  in  any  one  cloud  scene 
from  a  number  of  realizations  may  be  acceptable.  Greater  accuracy  (and  thus  the  iterative 
threshold  process)  is  required  when  modeling  individual  cloud  scenes. 
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The  structure  of  the  stochastic  fields  generated  with  the  BSW  model  depends  on  two 
model  parameters;  the  number  of  waves  and  the  wavelength(s)  (more  than  one  wave¬ 
length  may  be  used  in  any  one  scene).  Sequences  of  two-dimensional  cloud  scenes  pro¬ 
duced  with  varying  numbers  of  waves  and  wavelengths  are  shown  in  Figs.  3  and  4.  Each  of 
the  scenes  in  the  two  figures  has  horizontal  dimensions  of  50  km  by  50  km,  and  all  are 
binary  cloud/no  cloud  scenes  with  50%  cloud  cover. 

The  six  scenes  shown  in  Fig.  3  were  all  generated  with  two  different  wavelengths; 
half  of  the  total  number  of  waves  had  X  =  40  and  the  remainder  had  X  =  55  km.  By  compar¬ 
ing  the  cloud  fields  generated  with  smaller  and  larger  number  of  waves,  it  is  clear  that  a 
large  number  of  waves  (approximately  200)  is  required  to  produce  realistic  cloud  fields 
with  these  wavelengths.  This  is  unlike  the  application  of  the  BSW  algorithm  to  cloud  cli¬ 
matology  where  a  small  number  of  waves  (N  =  12)  may  be  sufficient  (Ref.  1),  and  climatolo¬ 
gy  is  based  on  a  large  number  of  realizations.  Unfortunately,  due  to  the  large  number  of 
waves  required  to  generate  any  single  cloud  scene,  the  initial  attraction  of  low  computa¬ 
tional  cost  offered  with  the  BSW  model  becomes  less  compelling. 

F  igure  4  shows  a  sequence  of  cloud  scenes  with  w  avelengths  ranging  from  10  km  to 
200  km  (all  generated  with  200  waves).  The  wavelength  is  a  measure  of  the  “scale  dis¬ 
tance”  of  the  clouds  in  the  scene.  Scale  distance  (as  defined  in  Ref.  1)  is  the  distance  over 
which  the  spatial  correlation  coefficient  remains  at  or  above  0.99.  The  wavelength  is  di¬ 
rectly  proportional  to  the  scale  distance  as 

X  =  c  *  r  (2.2-3) 

where  X  is  wavelength  (km),  r  is  scale  distance  (km)  and  c  is  a  multiplicative  constant.  The 
constant  c  was  taken  to  be  340  in  Ref.  1  (for  2-d  clouds)  and  256  in  Ref.  2  (for  3-d  clouds), 
corresponding  to  wavelengths  of  340  and  256  km,  respectively,  with  a  correlation  distance 
of  1  km.  We  found  (see  Fig.  4)  that  using  wavelengths  of  that  scale  resulted  in  cloud  scenes 
with  a  large  number  of  triangular  artifacts.  To  generate  natural-looking  individual  scenes, 
it  was  necessary  to  use  smaller  wavelengths  in  the  BSW  algorithm.  We  can  use  the 
qualitative  definition  of  scale  distance  to  produce  cloud  fields  representative  of  different 
cloud  types. 

Because  stratocumulus  clouds  tend  to  group  into  smaller  masses  than  stratus 
clouds,  we  expect  that  the  scale  distance  for  Sc  is  lower  than  that  for  St  clouds.  Accordingly, 
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5  Waves 


20  Waves 


50  Waves  100  Waves 


200  Waves  300  Waves 

Sequence  of  Binary  Cloud  Scenes  (50%  Cloud  Cover,  50  x  50  km 
Horizontal  Domain)  Generated  with  the  Two-Dimensional  BSW 
Method  with  Differing  Number  of  Waves 


>.  =  120  X  =  200 

Figure  4  Sequence  of  Binary  Cloud  Scenes  (50%  Cloud  Cover,  50  x  50  km 
Horizontal  Domain)  Generated  with  the  Two-Dimensional  BSW 
Method  with  Various  Values  for  the  Wavelength  (in  km) 
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we  use  smaller  wavelengths  in  the  BSW  model  to  produce  cloud  scenes  representative  of 
stratocumulus,  and  larger  wavelengths  for  stratus  cloud  type.  In  the  prototype  model  we 
define  a  set  of  two  u  avelengths  for  each  cloud  type:  40  and  55  km  for  Sc  and  Ac,  110  and  130 
km  for  St  and  As.  These  values  were  chosen  because  they  result  in  qualitatively  realistic 
cloud  distributions  within  each  realization.  With  this  in  mind,  these  values  are  not  directly 
related  to  the  scale  distance  (defined  in  terms  of  correlation  distance)  discussed  in  Ref.  1. 

Generate  Upper  Cloud  Surface  —  Based  on  visual  analysis  of  various  cloud  types  we 
chose  to  approximate  the  vertical  structure  of  stratiform  clouds  (the  only  types  considered 
in  the  prototype  model)  by  a  coarse  dome  with  higher  resolution  random  variations  super¬ 
imposed  upon  it.  It  was  clear  that  for  this  approximation,  variations  based  on  simple 
“white  noise”  would  not  be  realistic.  Instead,  random  variations  along  the  dome-like  struc¬ 
ture  could  be  generated  with  algorithms  approximating  fractional  Brownian  motion.  FBM 
models  are  a  subset  of  an  even  broader  group  of  random  fractal  models.  We  begin  this 
section  with  a  brief  overview  of  fractals  and  then  later  describe  the  application  of  this  tech¬ 
nique  to  the  generation  of  the  upper  cloud  surface  of  stratiform  clouds  within  the  cloud 
model. 


The  most  common  of  the  random  fractals  is  ordinary  Brownian  motion  (commonly 
known  as  the  random  walk  model).  In  one  dimension,  Brownian  motion  can  be  modeled  by 
sampling  a  random  variable,  V,  over  a  real  variable  t  (time).  The  function  V(t)  represents 
the  displacement  of  a  particle  (as  measured  from  the  origin)  undergoing  Brownian  motion. 
Increments  in  V(t)  are  Gaussian  distributed  with  variance  proportional  to  the  time  differ¬ 
ence  as  follows  (Ref.  9): 

Var(  V(t2)  -  V(tx)  )  «  |  t2  -  tx  |  .  (2.2-4) 

Such  increments  are  independent  and  statistically  self-similar.  That  is,  if  we  were  to  ex¬ 
pand  or  contract  the  one-dimensional  function,  V(t),  in  the  time  dimension  we  would  gen¬ 
erate  a  statistically  indistinguishable  function  with  increments  scaled  appropriately, 

V(t0  +  t)  -  V(t0)  is  scaled  to  4=  (V(t0  +  rt)  -  V(t0))  < 2-2-5) 

Jr 

where  r  >  0.  An  example  of  the  scaling  properties  of  Brownian  motion  is  shown  in  Fig.  5. 
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Figure  5  Brownian  Motion  With  Scale  Factors  Ranging  from  r=l/8  to  r=8 
Corresponding  to  Expanding  and  Contracting  the  Original 
Function  Along  the  Horizontal  Direction  (From  Ref.  3) 

Fractional  Brownian  motion  is  a  generalization  of  Brownian  motion  in  which 
Eq.  2.2-4  is  modified  to 

Var(  V(t2)  -  VUj)  )  «  |  t2  -  tx  |  (2H)  (2.2-6) 

where  H,  the  Hurst  parameter,  can  vary  between  0  and  1.  Unlike  Brownian  motion  (i.e., 
H  =  0.5),  increments  of  FBM  are  not  independent,  but  are  positively  (H  >  0.5)  or  negatively 
(H  <  0.5)  correlated.  As  a  result,  FBM  can  be  used  to  model  random  fields  representative  of 
highly  correlated  stratus  clouds  or  somewhat  less  correlated  stratocumulus  clouds  in  two, 
three  or  four  dimensions.  Figure  6  shows  one-dimensional  fractional  Brownian  motion 
with  various  values  for  the  Hurst  parameters. 

One  elementary  method  for  approximating  fractional  Brownian  motion  is  the  mid¬ 
point  displacement  method.  In  this  method,  FBM  is  generated  over  a  specified  interval 
(e.g.,  0  <  t  <  1)  by  a  recursive  interpolation  algorithm.  The  value  of  the  function  at  time 
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Figure  6  Fractional  Brownian  Motion  With  Various  Values 

of  the  Hurst  Parameter,  Lacunarity  Parameter  =  0.5 


zero,  V(0),  is  set  to  zero  and  V(  1)  is  sampled  from  a  Gaussian  distribution  with  variance  o  2. 
The  first  step  consists  of  calculating  V(  1/2)  as  the  average  ofV(O)  and  V(l)  and  then  adding 
a  Gaussian  random  offset  with  variance  A2  to  that  averaged  value.  In  successive  steps,  we 
continue  to  calculate  consecutive  midpoints,  adding  random  offsets  with  corresponding 
variance  for  each.  Figure  7  shows  the  function  V(t)  after  two  steps  of  the  midpoint 
displacement  algorithm.  Midpoint  random  offsets  are  indicated  by  the  vertical  line 
segments.  It  can  be  shown  (Ref.  3)  that  at  step  n  the  variance  of  the  random  offset  is 


A 


2 

n 


(2n)2H 


(1-2 


2H-2 


). 


(2.2-7) 


At  each  step,  the  resolution  is  increased  by  a  factor  of  2  with  the  number  of  points  in¬ 
creasing  as  2n+l.  Using  this  method,  visible  artifacts  of  the  first  few  steps  in  the  recursion 
are  frequently  visible  in  the  final  function.  The  Successive  Random  Additions  (SRA)  meth¬ 
od  is  an  extension  of  the  midpoint  displacement  method  developed  to  avoid  these  artifacts. 
In  this  method  random  offsets  of  suitable  variance  are  added  to  all  of  the  points  at  each 
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Figure  7  Two  Steps  of  the  Midpoint  Displacement  Method 

step  in  the  recursion,  not  just  at  the  midpoints  (resulting  in  slightly  higher  computational 
costs  than  the  standard  midpoint  displacement  technique). 

A  further  extension  to  the  SRA  method  provides  the  user  with  more  flexibility  in  the 
generation  of  the  final  function .  The  extension  allows  for  interpolation  to  points  other  than 
the  midpoint,  thus  increasing  the  resolution  by  factors  other  than  2  at  each  stage.  The  pa¬ 
rameter  that  controls  the  rate  of  interpolation  in  the  algorithm  is  the  lacunarity  parame¬ 
ter,  r.  Varying  r  changes  the  total  number  of  steps  required  to  generate  the  fractional 
Brownian  motion  and  thus  the  amount  of  variability  in  the  final  function.  The  variance  of 
the  random  offsets  in  the  SRA  method  takes  on  a  slightly  more  complicated  form  than  in 
the  midpoint  displacement  algorithm,  but  also  depends  on  the  value  of  n.  The  variance  can 
be  written  as 

An  2  =  y  (l  ~  r2_2H)  (rn)2H  .  (2.2-8) 

A  sequence  of  time  series  generated  with  various  r  values  (0  <  r  <  1)  is  shown  in  Fig.  8. 

In  the  prototype  cloud  model,  we  use  the  one-dimensional  SRA  method  to  generate 
random  structure  along  line  segments  forming  the  coarse  backbone  of  the  upper  cloud  sur¬ 
face.  The  coarse  backbone  is  first  generated  by  traversing  the  two-dimensional  cloud/no 
cloud  field  generated  with  the  BSW,  identifying  continuous  lines  of  cloud  elements  (the 
field  is  traversed  in  both  the  x  and  y  directions  independently).  Each  continuous  line  of 
cloud  elements  is  divided  into  four  smaller  segments  and  the  coarse  structure  built  upon 
those  segments  as  shown  in  Fig.  9. 
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Figure  8  Fractional  Brownian  Motion  with  Various  Values  of  the 
Lacunarity  Parameter,  Hurst  Parameter  =  0.7 

Coarse  structure  is  defined  so  that  the  apex  of  the  larger  clouds  (i.e.,  those  whose 
horizontal  extent  is  at  least  10%  of  the  total  horizontal  cloud  domain  size)  reaches  the  us¬ 
er-specified  cloud  top  height.  The  apex  of  the  smaller  cloud  elements  (those  whose  horizon¬ 
tal  extent  is  less  than  10%  of  the  cloud  domain  size)  extends  to  50%  of  the  specified 
thickness  above  the  base.  Having  specified  the  end  points  of  each  of  the  four  segments,  the 
SRA  method  is  used  to  generate  random  structure  between  each  set  of  adjacent  end  points. 
Height  values  generated  in  this  manner  are  stored  as  HGTx(x,y)  and  HGTy(x,y),  corre¬ 
sponding  to  traversing  the  cloud  field  in  the  x  and  y  directions,  respectively.  A  smoothed 
upper  cloud  surface  is  defined  by  averaging  the  two  heights  at  each  x-y  gridpoint  as 

HGT8moothed(x,y)  =  \  ( HGTx(x,y)  +  HGTy(x,y) ).  (2.2-9) 

This  technique  produces  upper  cloud  surfaces  that  overall  are  quite  realistic,  but 
which  sometimes  result  in  edge  artifacts  as  discussed  in  Section  2.2.3  and  shown  in 
Fig.  13.  In  that  figure,  sharp  drop-offs  can  be  seen  near  some  areas  of  the  cloud  ecge.  Be¬ 
cause  of  these  artifacts,  we  have  replaced  the  method  outlined  here  with  an  alternate  tech¬ 
nique  in  the  interim  model. 
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Figure  9  Fundamental  Structure  Used  in  Dome-Building  Process  to  Generate 
Upper  Cloud  Surface 


Generate  Lower  Cloud  Surface  —  We  use  a  two-dimensional  version  of  the  SRA 
model  described  in  the  previous  section  to  generate  the  relatively  smooth  yet  variable 
cloud  base  surfaces  characteristic  of  stratiform  clouds.  The  lower  cloud  surface  is  defined 
as  a  2-d  perturbation  field.  The  SRA  algorithm  is  used  to  generate  the  perturbation  field 
which  is  then  scaled  to  have  mean  equal  to  the  user-specified  cloud  base  and  a  standard  de¬ 
viation  of  10%  of  the  cloud  layer  thickness.  In  the  absence  of  quantitative  data  of  the  vari¬ 
ance  of  typical  cloud  base  surfaces,  a  value  of  10%  is  assumed  because  it  results  in  visually 
realistic  lower  cloud  surfaces. 

In  two  dimensions  we  initialize  the  SRA  algorithm  at  each  of  the  four  outer  corners 
of  a  two-dimensional  square  grid.  Initially  all  four  corners  are  set  to  zero.  We  then  interpo¬ 
late  recursively  (using  bilinear  interpolation)  to  compute  the  nominal  value  of  the  function 
at  each  grid  point.  At  each  step  the  value  of  the  function  at  each  “new”  point,  Vnew(x,y),  is 
the  weighted  average  of  the  four  nearest  “old”  points  (i.e.,  those  grid  points  computed  dur¬ 
ing  the  previous  step  in  the  recursion).  Weighting  is  based  on  the  relative  distance  from  the 
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new  point  to  each  of  the  old  points  as  shown  in  Fig.  10.  The  distance  values,  dx  and  dy  vary 
between  zero  and  one,  and  are  used  in  the  interpolation  as  follows: 

Vnew(x,y)  =  (1-dx)  *  (1-dy)  *  V0id(x0,yo)  + 

(1-dx)  *  dy  *  Void(x0,yi)  + 

dx  *  (1-dy)  *  Vold(xi,y0)  +  (2.2-10) 

dx  *  dy  *  Vold(xi,yi). 


Random  offsets  are  then  added  to  Vnew  at  all  grid  points  before  proceeding  to  the  next  step 
in  the  recursion.  Here,  as  in  1-d,  we  can  tailor  the  structure  of  the  cloud  base  surface  by 
carefully  selecting  Hurst  and  lacunarity  parameter  values.  Default  values  for  H  and  r  in 
the  prototype  cloud  base  model  are  0.8  and  0.5,  respectively,  for  all  cloud  types. 

Generate  Internal  Cloud  Structure  — T  T;thin  the  schedule  of  the  Cloud  Scene  Simu¬ 
lation  Project,  Task  2  (development  of  the  prototype  model)  occurred  much  before  the  anal¬ 
yses  and  studies  scheduled  as  Task  3.  Therefore,  in  the  absence  of  any  detailed  analysis  of 
the  internal  liquid  water  structure  of  stratiform  clouds,  we  decided  to  build  the  internal 
structure  of  the  cloud  scene  based  on  a  three-dimensional  stochastic  field  generation 
technique  for  the  reasons  outlined  in  Table  1.  To  facilitate  comparison,  we  implemented 
three-dimensional  versions  of  both  the  BSW  and  SRA  models  described  previously. 

G-27045 
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Figure  10  Variables  Used  in  Bilinear  Interpolation  (See  Eq.  2.2-10) 
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Comparison  of  the  internal  liquid  water  content  (LWC)  fields  resulting  from  both  of  these 
models  with  aircraft  measurements  is  an  important  aspect  of  Task  3  —  Studies  and  Analy¬ 
ses. 


The  extension  of  the  BSW  algorithm  to  three  dimensions  is  described  in  Ref.  2.  N 
waves  are  superimposed  in  the  three-dimensional  space  bounded  by  the  maximum  cloud 
base  and  top  heights.  Random  phase  and  orientation  are  required  for  each  wave  as  before, 
although  in  three  dimensions,  three  angles  (a,  p,y)  are  used  to  describe  the  orientation  of 
each  wave  with  respect  to  the  origin.  Figure  11  shows  a  sawtooth  wave  in  three-dimen¬ 
sions  where  the  wave  is  oriented  such  that  all  points  on  the  plane  ABC  have  the  same  wave 
height.  The  angles  (a,  p  and  y)  aTe  the  angles  that  the  shortest  line  between  the  origin  (O) 
and  the  plane  ABC  make  with  the  x,  y  and  z  axes,  respectively.  As  before,  it  was  found  that 
a  large  number  of  waves  (100  were  used  in  the  model)  was  needed  to  avoid  the  presence  of 
triangular  artifacts  in  the  final  field.  As  discussed  in  Ref.  2,  we  scale  the  vertical  coordi¬ 
nate  used  in  the  BSW  model  to  retain  the  correct  spatial  variations  between  the  horizontal 
and  vertical  coordinates.  The  vertical  coordinate  is  scaled  by  the  ratio  of  the  horizontal 
cloud  domain  extent  to  the  cloud  layer  thickness. 

The  extension  of  the  SRA  model  to  three  dimensions  is  straightforward.  We  initial¬ 
ize  the  function  at  the  eight  outer  corners  of  a  cube  and  proceed  to  interpolate  in  three  di¬ 
mensions  such  that  Vnew(x,y,z)  depends  on  the  value  of  the  function  V0id  at  each  of  eight 
surrounding  points.  Random  offsets  are  then  added  to  each  point  as  before.  By  varying  the 
Hurst  and  lacunarity  parameters,  (controlling  the  interpolation  rate  and  overall  amount 
of  variance  in  the  scene)  scenes  of  varying  statistical  character  can  be  produced.  Again,  we 
effectively  scale  the  vertical  coordinate  used  in  the  model  by  using  a  different  lacunarity 
parameter  in  the  vertical  than  in  the  horizontal  coordinate  directions. 

Once  the  3-d  perturbation  field  has  been  generated  (using  either  the  BSW  or  SRA 
model),  it  is  converted  to  a  field  of  liquid  water  density  values.  Assuming  a  horizontally  ho¬ 
mogeneous  temperature  profile,  the  temperature  and  vertical  location  of  each  level  in  the 
cloud  scene  is  used,  along  with  cloud  type  information,  to  specify  the  mean  liquid  water 
density  value  within  the  level  following  the  method  outlined  by  Feddes  in  Ref.  7.  Using 
Feddes’  method  for  a  given  cloud  type  and  temperature,  the  maximum  condensed  mois¬ 
ture  content  (in  g/m3)  is  retrieved  from  a  look-up  table.  (That  look-up  table  is  reproduced 
here  in  Table  3.)  Recall  that  only  stratus,  stratocumulus,  altostratus  and  altocumulus 
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Figure  11  Three-Dimensional  Geometry  Used  in  the  BSW  Method.  All  points  on 
the  Plane  ABC  have  Constant  Wave  Height.  The  line  OP  is  the  Shortest 
Distance  from  the  Origin  to  the  Plane  and  Has  Angles  a,  (3,  y  with  the 
x,y  and  z  Axes  (from  Ref.  2) 


cloud  types  are  simulated  in  the  prototype  model.  Other  moisture  values  are  listed  here  for 
comparison. 


The  actual  LWC  at  any  height  z  within  a  cloud  layer  is  some  fraction  of  the  maxi¬ 
mum  condensed  moisture  based  on  its  position  above  the  cloud  base.  It  can  be  given  by  the 
following: 


lwc(z)  =  (lwcmax)  (%  cover)  F 


(2.2-11) 
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Table  3  The  Maximum  Condensed  Moisture  (in  g/m3)  that  can  Occur 
in  a  Nonprecipitating  Cloud  as  a  Function  of  Cloud  Type 
and  Temperature  (from  Ref.  7).  Cloud  Types  simulated  in 
the  Prototype  Model  are  Highlighted 


TEMPERATURE  (DEGREES  C) 

CLOUD 

TYPE 
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.70 
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cu 
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3.0 

3.0 

3.0 

3.0 

3.0 

3.0 

3.0 

3.0 

3.0 

NS 

.35 

.40 

.45 

.50 

.60 

.60 

.75 

.90 

.90 

.90 

AC 

.25 
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.40 

.40 

.45 

.60 
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.70 

.70 

AS 

.15 
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.25 
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.50 
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cs 
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.20 

.20 
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Cl 
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.20 

cc 

.05 

.05 

.05 

.05 

.10 

.10 
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.15 

.15 

CB 

6.5 

6.5 

6.5 

6.5 

6.5 

6.5 

6.5 

6.5 

6.5 

6.5 

where  lwcmax  is  the  maximum  condensed  moisture  (a  function  of  cloud  type  and  tempera¬ 
ture),  %cover  is  the  fractional  cloud  cover  in  the  layer  and  F  is  a  function  of  percentage 
height  of  z  above  the  cloud  base.  The  fraction,  F,  is  determined  from  empirically-derived 
curves  shown  in  Ref.  7.  One  of  those  curves  has  been  included  here  as  Fig.  12  relating  the 
percent  height  above  cloud  base  to  the  fraction  of  maximum  condensed  moisture  for  Sc  and 
Ac  clouds.  Figure  12  is  concerned  only  with  non-precipitating  clouds  (and  thus  F  only 
reaches  a  maximum  of  approximately  75%).  The  equation  of  this  curve  is 

F  =  0.236  +  0.018974  (%)  -0.00018974  (%)2  (2.2-12) 


where  (%)  is  shorthand  for  the  percent  height  above  cloud  base  (0-100).  As  an  example,  let 
us  find  the  mean  LWC  at  a  level  200  meters  up  into  a  600  meter  stratocumulus  cloud  layer 
(40%  fractional  coverage)  where  the  temperature  at  that  height  is  +8  deg  C.  First,  we  find 
the  maximum  condensed  moisture  value  for  a  stratocumulus  cloud  at  that  temperature 
from  Table  3  to  be  0.7  g/m3.  Then,  using  Fig.  12,  we  read  off  a  percent  of  maximum 
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Figure  12  Profile  of  Percent  of  Maximum  Condensed  Moisture  for  Sc  and  Ac 
Cloud  types  Used  in  the  Computation  of  Mean  LWC  for  a  Given 
Level  in  a  Cloud  Layer  (From  Ref.  7) 


condensed  moisture  of  65%,  corresponding  to  a  percent  height  above  the  base  of  33%.  The 
final  mean  value  of  the  layer  is  then 


Iwc  =  (0 . 70)(0 . 4)(0 . 65)  =  0 . 182  g/m3  .  (2.2-13) 
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At  each  vertical  level  in  the  3-d  cloud  field  we  transform  the  zero-mean  Gaussian 
field  to  have  mean  LWC  (computed  as  above)  and  coefficient  of  variation  of  10%  (where  the 
coefficient  of  variation  is  a  measure  of  variation  with  respect  to  the  mean).  Choosing  the 
coefficient  of  variation  equal  to  10%  was  convenient  and  reasonable  for  the  prototype 
model.  Later  modifications  to  the  cloud  model  will  provide  a  distributional  form  consistent 
with  results  from  an  analysis  of  cloud  data. 

Finally,  as  a  means  to  introduce  variability  near  the  cloud  edges,  we  set  those  field 
values  near  the  edge  that  are  below  a  certain  value  ( V(x,y)  <  V  (1-c))  equal  to  zero  (where  V 
and  c  are  the  mean  and  coefficient  of  variation  of  the  3-d  cloud  field,  respectively).  This  re¬ 
sults  in  more  realistic  cloud  scenes  with  holes  and  disconnected  cloud  elements  near  the 
edges  as  found  in  nature. 

Write  Three-dimensional  Cloud  Field  to  Output  File  —  The  output  module  writes 
the  three-dimensional  array  of  liquid  water  content  values  to  an  output  file.  Each  of  the 
two  possible  cloud  layers  in  the  prototype  model  are  written  to  separate  files  (with  “.L”  and 
“.M”  appended  to  the  filename  for  low  and  middle  layers,  respectively).  This  output  mo¬ 
dule  is  called  by  the  main  interface  routine  and  is  designed  to  be  replaceable  if  the  user  re¬ 
quires  a  different  format  to  store  the  cloud  data. 

A  header  record  is  generated  at  the  start  of  each  of  the  output  files.  This  header  con¬ 
tains  the  size  and  resolution  of  the  cloud  domain  and  the  height  of  the  lowest  cloud  ele¬ 
ment.  This  information  about  layer  position  and  scale  can  be  used  as  input  for  further 
processing  of  the  cloud  field.  See  Ref.  6  for  further  details  about  the  content  and  format  of 
the  output  files. 

2.2.3  Results  and  Conclusions 

The  prototype  model  was  developed  rapidly  to  demonstrate  a  capability  to  produce 
realistic  three-dimensional  cloud  fields.  Because  the  Studies  and  Analyses  task  occurs  lat¬ 
er  in  the  project,  we  did  not  emphasize  the  generation  of  fields  with  the  correct  spatial  dis¬ 
tribution  of  liquid  water  at  this  early  stage.  Instead  we  produced  clouds  with  realistic 
appearance  and  set  up  the  machinery  to  generate  liquid  water  content  structure.  Compar¬ 
ative  evaluation  of  the  various  stochastic  field  generation  techniques  will  be  an  important 
task  later  in  the  project. 
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Figures  13  and  14  show  cloud  scenes  produced  with  the  prototype  model.  In  the  first 
figure  we  have  a  rather  realistic  50%  stratus  layer  scene.  The  second  figure  contains  a  less 
realistic  realization  of  the  same  scene,  generated  with  identical  input  parameters  with 
exception  of  the  random  number  seed.  These  two  figures  show  both  the  success  of  the  rapid 
prototype  model  and  the  need  for  improvement. 

Areas  in  need  of  improvement  include  the  generation  of  the  horizontal  cloud  field 
and  the  upper  bounding  cloud  surface.  We  found,  based  on  a  large  number  of  scene  simula¬ 
tions,  that  even  with  a  largp  umber  of  waves  and  two  wavelengths,  triangular  artifacts 
resulting  from  the  “sawtooth”  nature  of  the  BSW  algorithm  were  frequently  apparent.  To 
avoid  these  artifacts,  other  random  stochastic  field  generation  techniques  were  investi¬ 
gated  for  use  in  future  versions  of  the  cloud  model  and  will  be  discussed  later  in  the  report. 

Also  apparent  in  Fig.  14  are  steep  vertical  cloud  edges  resulting  from  the  “dome¬ 
building”  process  used  to  create  the  upper  cloud  surface.  Although  the  dome-shaped  struc¬ 
ture  may  be  an  acceptable  approximation  for  some  stratiform  cloud  types  in  a  prototype 


Figure  13  50%  Stratus  Cloud  Layer  Generated  With  the  Prototype  Model 

(20  x  20  km  Horizontal  Domain) 
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Figure  14  50%  Stratus  Cloud  Layer  Generated  With  the  Prototype 

Model  (20  x  20  km  Horizontal  Domain).  Artifacts  From  the 
BSW  Model  are  Clearly  Visible 


model,  it  does  not  represent  the  natural  variability  in  cloud  edges  and  is  too  inflexible  to 
use  for  other  cloud  types.  In  version  2.0  we  implemented  a  different  method  to  build  verti¬ 
cal  cloud  structure. 

Additional  results  from  the  prototype  model  include  the  need  to  modify  the  memory 
allocation  within  the  software  to  allow  the  user  more  flexibility  in  specifying  the  size, 
shape  and  resolution  of  the  cloud  domain,  as  well  as  a  need  to  fine-tune  the  parameters 
used  within  the  model  (specifically  the  wavelengths  used  in  the  BSW  algorithm  and  the 
Hurst  and  lacunarity  parameters  in  the  SRA  algorithm).  All  of  the  results  and  ideas 
generated  during  this  task  were  considered  during  the  requirements  analysis  phase  of 
Task  4  —  Develop  Model  Version  2.0. 
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2.3  THE  INTERIM  MODEL  (VERSION  2.0) 


The  interim  model  (see  Ref.  10)  is  built  upon  the  tools  and  software  developed  for 
the  prototype  model.  It  incorporates  various  improvements  to  the  previous  model  as  well 
as  added  capabilities.  Improvements  in  the  generation  of  the  horizontal  distribution  of 
clouds  and  vertical  structure  (as  discussed  in  Section  2.2.3)  are  included.  Added  capabili¬ 
ties  include  a  prototype  cirriform  model,  a  cloud  shadow  model  and  a  unique  cloud  data  vi¬ 
sualization  technique  to  support  scene  visualization  at  the  Engineer  Topographic 
Laboratories  (ETL).  Each  of  these  modifications  and  additions  are  covered  in  greater  de¬ 
tail  in  following  sections.  We  begin,  however,  with  a  discussion  of  requirements  analysis 
for  Task  4. 

2.3.1  Interim  Model  Requirements  and  Design 

As  in  Tables  1  and  2  we  present  (in  Table  4)  the  requirements  applicable  to  the 
interim  model  and  the  corresponding  model  design  decisions  made  to  satisfy  each  require¬ 
ment.  A  few  of  the  requirements  considered  for  the  interim  model  carry  over  from  the  pro¬ 
totype  model.  For  example,  we  continue  to  model  only  the  spatial  component  of  the  cloud 
scene  (not  its  temporal  development).  We  also  continue  to  emphasize  portability  and  main¬ 
tainability  in  the  interim  model.  All  code  is  written  in  standard  FORTRAN  77  and  no  ex¬ 
ternal  databases  of  meteorological  information  are  required.  By  keeping  strictly  to  these 
ideas  we  hope  to  minimize  any  future  difficulties  integrating  with  other  SWOE  models. 

Keeping  in  mind  the  goal  of  developing  a  cloud  model  to  simulate  three  main  cloud 
types,  stratiform,  cirriform  and  cumuliform,  we  began  with  stratiform  in  the  prototype 
model.  We  add  a  prototype  cirriform  capability  in  the  interim  model.  In  the  final  version  of 
the  model,  we  will  develop  a  model  for  cumuliform  development. 

The  fourth  and  fifth  requirements  listed  in  Table  4  refer  to  the  development  of  addi¬ 
tional  capabilities  external  to  the  cloud  model  itself.  One  early  use  of  the  cloud  model,  for 
surface  energy  budget  studies,  required  cloud  shadow  locations.  We  designed  software  to 
compute  the  location  of  shadows  (in  a  user-specified  ground  domain)  cast  by  a  given  three- 
dimensional  cloud  scene.  This  cloud  shadow  package  is  distinct  from  the  cloud  model  soft¬ 
ware  in  keeping  with  the  modular,  low-maintenance  emphasis  in  the  program. 

To  aid  and  participate  in  SWOE  simulation  demonstrations  at  ETL,  we  designed  vi¬ 
sualization  software  to  convert  cloud  model  output  files  to  a  form  that  can  be  used  in  ETL’s 
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Table  4  Requirements  and  Design  for  Interim  Model 


■ 

INTERIM  MODEL  REQUIREMENTS 

DESIGN  DECISIONS 

1 

Continue  rapid  development  in  order  to  incorpo¬ 
rate  SWOE  user  feedback. 

Simulate  cloud  scenes  in  three  dimensions  only. 

Do  not  model  temporal  dimension. 

2 

Continue  to  work  toward  100%  compatibility  with 
other  SWOE  team  members. 

Continue  to  write  software  in  standard  FORTRAN 

77.  Make  software  stand-alone  (i.e.,  require  no 
external  databases,  etc.) 

3 

Continue  to  expand  model  capabilities. 

Add  prototype  cirriform  model  and  thus  capability 
to  produce  three  layer  scenes. 

B 

Provide  capability  to  generate  ground  shadow 
map  of  any  cloud  scene. 

Develop  shadow  post-processor. 

5 

Deliver  cloud  scenes  to  ETL  for  use  in  scene  vi¬ 
sualization. 

Develop  visualization  tools  to  generate  colored 
polygonal  cloud  surfaces. 

6 

Increase  model  efficiency. 

Optimize  code  (e.g.,  the  process  of  computing  a 
cloud  cover  threshold). 

H 

Provide  user  with  greater  flexibility  in  cloud  layer 
size  and  resolution. 

Improve  memory  management.  Allow  user  to  sim¬ 
ulate  a  rectangular  cloud  domain  with  different 
resolution  in  each  direction. 

8 

Improve  realism  of  horizontal  distribution  of  cloud 
elements. 

Replace  BSW  algorithm  with  a  fractal  technique 
(SR  A). 

9 

Improve  cloud  edges  and  overall  shape  of  upper 
cloud  surface. 

Replace  “dome-building"  method  with  polynomial 
function  of  fractal  field. 

10 

Provide  easier  output  file  management. 

Concatenate  all  layers  into  one  output  file. 

scene  generation  system.  Through  close  contact  with  ETL  a  set  of  requirements  was  estab¬ 
lished.  The  ETL  scene  generation  system  uses  a  standard  graphics  technique  of  approxi¬ 
mating  a  natural  or  computer-generated  surface  with  a  large  number  of  colored  polygonal 
surfaces.  We  chose  to  combine  the  Marching  Cubes  isosurface  algorithm  (discussed  in  Sec¬ 
tion  2.5)  with  variable  coloration  based  on  cloud  density  and  orientation  for  added  real¬ 
ism.  Output  from  the  visualization  software  is  used  at  TASC  (on  a  Stardent  computer)  as 
well  as  at  ETL. 

The  last  five  requirements  in  Table  4  concern  improvements  to  the  prototype  cloud 
model.  Among  them,  a  more  flexible  memory  allocation  modulethatwe  designed  to  accom¬ 
modate  the  broader  range  of  geometric  scales  (i.e.,  width-to-height  ratios)  encompassed  by 
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cirriform  and  stratiform  cloud  types  in  the  interim  model.  Also,  based  on  experience 
gained  with  the  prototype  model  (discussed  in  Section  2.2.3),  changes  were  made  to  in¬ 
crease  the  visual  realism  of  the  liquid  water  content  fields.  Points  8  and  9  from  Table  4  re¬ 
fer  to  those  changes.  Lastly,  we  modified  the  output  module  to  concatenate  all  cloud  layers 
for  a  single  scene  into  a  single  disk  file.  A  description  of  each  of  the  major  model  modifica¬ 
tions  is  provided  in  the  next  subsection. 

2.3.2  Modifications  Included  In  the  Interim  Model 

The  interim  model  is  composed  of  six  major  model  procedures  where  overall  pro¬ 
cessing  logic  is  similar  to  that  of  the  prototype  model.  The  main  procedures  are: 

•  Acquire  model  input  parameters 

•  Generate  horizontal  cloud  field 

•  Generate  upper  cloud  surface 

•  Generate  lower  cloud  surface 

•  Generate  internal  cloud  structure 

•  Write  three-dimensional  cloud  field  to  output  file. 

Though  every  module  was  modified  to  some  extent  to  accommodate  various  minor 
upgrades  to  the  software  between  Version  1.0  and  2.0,  the  most  important  modifications 
were  in  only  two  modules.  We  present  those  in  the  following  two  subsections. 

Generate  Horizontal  Cloud  Field  —  Studies  have  shown  that  the  horizontal  struc¬ 
ture  of  clouds  and  cloud  water  approximately  follows  fractal  scaling  laws  over  a  broad 
range  of  scales  (Refs.  11  and  12).  Others  showed  that  this  fractal  behavior  varies  as  a  func¬ 
tion  of  cloud  type  (Ref.  13).  We  found,  through  working  with  the  SRA  fractal  algorithm  in 
the  prototype  model,  that  it  is  an  efficient  way  to  compute  stochastic  fields  with  a  high  de¬ 
gree  of  control  over  the  structure  of  the  final  field.  Therefore,  we  implemented  (in  the  inter¬ 
im  model)  a  two-dimensional  version  of  the  SRA  model  to  simulate  the  horizontal 
distribution  of  the  cloud  fields. 

We  have  discussed  the  1-d  SRA  algorithm  used  to  build  the  upper  cloud  surface  (in 
the  prototype  model),  the  2-d  SRA  algorithm  used  to  generate  the  cloud  base  surface  (in 
both  model  versions),  and  the  3-d  SRA  algorithm  to  produce  internal  liquid  water  density 
fields  (in  both  versions).  In  this  section  we  describe  the  2-d  SRA  algorithm  used  to  produce 
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the  horizontal  cloud/no  cloud  distributions  typical  of  distinct  cloud  types  (e.g.,  cirriform 
and  stratiform)  in  the  interim  model. 

Recall  the  iterative  process  that  is  the  basis  of  the  SRA  algorithm  in  2-d.  Starting 
with  values  of  zero  at  each  of  four  comer  points,  we  continue  to  interpolate  and  add  ran¬ 
dom  offsets  within  the  grid  until  the  desired  resolution  is  attained.  A  sequence  of  “snap¬ 
shots”  taken  at  consecutive  steps  in  the  generation  of  a  two-dimensional  random  fractal 
image  (256  by  256  grid  points)  is  shown  in  Fig.  15.  In  this  sequence,  the  intensity  of  the 
field  values  is  represented  by  a  grey  scale,  where  grid  points  with  high  numerical  values 
are  lighter  and  darker  grid  points  have  lower  values.  Figure  15  shows  that  much  of  the 
large  scale  structure  in  the  fractal  field  is  apparent  even  after  one  step  in  the  interpolation 
process.  The  variance  of  the  random  offsets  added  at  each  successive  step  decreases  as  in 
Eq.  2.2-8. 

To  use  this  gridded  realization  of  a  continuous  random  field  to  generate  a  binary 
(i.e.,  cloud/no  cloud)  scene,  we  select  a  threshold  value  to  produce  the  desired  coverage.  In 
Version  2.0  of  the  cloud  model,  the  threshold  value  is  computed  from  a  histogram  of  the 
field  values.  As  before,  all  grid  points  with  field  values  above  the  threshold  are  defined  as 
“cloud,”  and  all  others  are  defined  as  “clear.”  Figure  16  shows  a  binary  scene  produced 
from  the  last  grey-scale  image  displayed  in  Fig.  15  with  the  threshold  chosen  to  yield  50% 
coverage. 

As  in  the  case  of  one-dimensional  fractional  Brownian  motion,  the  visual  appear¬ 
ance  and  statistical  characteristics  of  fields  generated  with  the  SRA  algorithm  are  highly 
dependent  on  the  values  of  the  Hurst  and  lacunarity  parameters.  We  can  exploit  this  de¬ 
pendency  to  produce  fields  characteristic  of  a  variety  of  cloud  types.  Figure  17  shows  the 
effect  of  varying  H  from  0.2  to  0.8  in  four  2-d  cloud  scenes  (with  50%  cloud  cover).  We  see 
that  the  large  scale  structure  remains  invariant  for  different  H  values.  Only  the  smaller- 
sc^le  variability  (i.e.,  the  roughness)  of  the  field  changes.  We  can  use  this  property  to  pro¬ 
duce  fields  representative  of  the  more  wispy,  scattered  cirrus  or  stratocumulus  cloud  types 
by  using  small  H  values  (near  0.4).  Likewise,  higher  values  of  H  (near  0.7)  produce  more 
solid  stratus-type  cloud  fields. 

The  lacunarity  parameter  provides  another  degree  of  freedom.  Varying  it  effective¬ 
ly  varies  the  scene  texture.  Lower  r  values  (r  <  0.5)  produce  scenes  with  more,  but  smaller 
cloud  elements.  Higher  values  of  r  (r  >  0.5)  produce  scenes  with  fewer,  but  larger  cloud 
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Step  7  Step  8 

Figure  15  Series  of  Images  Taken  at  Consecutive  Stages  in  the  Development  of  a 

Two-Dimensional  Cloud  Field  Using  the  Method  of  Successive  Random 
Additions  (H=0.5,  r  =  0.5) 
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Figure  16  Binary  Cloud  Field  (50%  Cloud  Cover)  Generated  By  Applying 
a  Threshold  Value  to  the  Fractal  Field  of  Fig.  15 

elements.  The  number  of  points  N(n)  in  each  dimension,  generated  at  step  n  in  the  recur¬ 
sion  is  given  by 


(2.3-1) 


where  ’INTI  J  ’  represents  the  integer  portion  of  the  argument.  From  this  equation  one  can 
see  that  lower  r  values  generate  larger  numbers  of  gridpoints  at  each  iteration.  Conse¬ 
quently,  fewer  iterations  are  required  to  produce  the  desired  resolution.  Since  the  variance 
of  the  random  additions  decreases  with  each  iteration,  the  initially  large  variance  tends  to 
persist  more  for  lower  values  of  r.  In  contrast,  higher  values  of  r  tend  to  produce  smoother 
fields  using  more  iterations.  Examples  of  cloud  fields  created  with  various  lacunarity  pa¬ 
rameter  values  are  shown  in  Fig.  18. 

Given  the  effects  that  variations  in  the  Hurst  and  lacunarity  parameters  have  on 
the  spatial  characteristics  of  the  final  field,  we  can  generate  realistic  images  of  various 
cloud  types  in  two  dimensions.  Figure  19  provides  examples  of  2-d  stratus,  stratocumulus 
and  cirrus  cloud  distributions  generated  using  the  SRA  algorithm. 


34 


H=0.6  H=0.8 


Figure  17  Sequence  of  Binary  Cloud  Scenes  (50%  Cloud  Cover)  Generated 
with  the  Two-Dimensional  SRA  Method  with  Various  Values  for 
the  Hurst  Parameter  (r  =  0.5) 
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r=0.6  r=0.8 


Figure  18  Sequence  of  Binary  Cloud  Scenes  (50%  Cloud  Cover)  Generated  with 
the  Two-Dimensional  SRA  Method  with  Various  Values  for  the 
Lacunarity  Parameter  (H=0.5) 
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Stratus 


Stratocumulus 


Cirrus 


Figure  19  Binary  Cloud  Scenes  (50%  Cloud  Cover,  10  x  10  km  Horizontal 
Domain)  Generated  with  the  Two-Dimensional  SRA 
Algorithms  for  Various  Cloud  Types 
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The  prototype  cirriform  model,  included  in  the  interim  model,  allows  for  indepen¬ 
dent  lacunarity  parameter  values  in  the  x  and  y  Cartesian  coordinate  directions.  By  using 
different  r  values  along  the  axes,  we  are  able  to  simulate  fibrous-like  cirriform  clouds.  Val¬ 
ues  used  in  the  interim  model  for  the  Hurst  and  lacunarity  parameters  for  each  of  the  main 
cloud  types  are  listed  in  Table  5.  Future  results,  primarily  from  Task  3,  may  lead  us  to 
modify  these  values  from  their  current  defaults  to  better  match  observed  cloud  statistics. 

Generate  Upper  Cloud  Surface  —  Once  the  horizontal  cloud/no  cloud  field  is  defined 
using  the  method  outlined  above,  upper  and  lower  cloud  surfaces  are  built.  In  the  interim 
model,  we  define  the  height  of  the  upper  surface  at  each  grid  point  to  be  a  function  of  the 
fractal  field  value  at  that  point.  In  general,  this  method  produces  higher  cloud  tops  toward 
the  center  of  cloudy  regions,  where  the  fractal  field  generally  has  higher  numerical  value, 
and  lower  cloud  tops  toward  the  edges.  This  qualitative  effect  corresponds  well  to  what  we 
see  frequently  in  nature. 

We  found  that  a  function  of  the  following  form 

HGT(x,y)  =  Av/(V(x,y)  -  Vmin)  +  BASE  (2.3-2) 

where 

A  =  (TOP  -  BASE)  /  J(Wmax  -  Vmin) 

BASE  is  the  user-specified  base  height 
TOP  is  the  user-specified  top  height 
Vmin  is  the  minimum  field  value 
Vmax  is  the  maximum  field  value 

Table  5  Default  Values  for  the  Hurst  and  Lacunarity  Parameters 
Used  in  the  Generation  of  the  Horizontal  CloudyNo  Cloud 
Field  for  Various  Cloud  Types 


STRATUS 

STRATOCUMULUS 

CIRRUS 

CIRROSTRATUS 

H 

0.7 

0.5 

0.4 

0.6 

r* 

0.4 

0.2 

0.5 

0.5 

rv 

0.4 

0.2 

0.3 

0.3 
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produced  visually  realistic  cloud  top  surfaces.  Three  sample  cloud  scenes  generated  using 
the  improved  horizontal  distribution  and  upper  surface  generation  techniques  described 
here  are  shown  in  the  next  section. 

2.3.3  Results  And  Conclusions 

The  interim  model  incorporates  many  improvements  within  the  general  structure 
of  the  prototype  model.  Cloud  scenes  generated  with  the  interim  model  appear  qualitative¬ 
ly  more  natural  and  realistic  than  prototype  model  simulations.  In  Figs.  20, 21  and  22  we 
show  simulated  cloud  scenes  of  various  types:  stratus,  stratocumulus  and  cirrus,  respec¬ 
tively.  All  are  single-layer  scenes  with  60%  fractional  coverage  extending  over  a  10  km  x  10 
km  horizontal  domain.  These  scenes  were  rendered  by  filling  each  voxel  (i.e.,  volume  grid 
point)  with  semi-transparent  particles  whose  opacity  is  based  on  the  water  content  in  the 
voxel.  Color  is  simulated  using  a  simple  shading  model.  We  display  the  scenes  as  viewed 


Figure  20  60%  Stratus  Cloud  Layer  Produced  with  the  Interim  Cloud  Model 
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Figure  21  60%  Stratocumulus  Cloud  Layer  Produced  with  the  Interim 

Cloud  Model 


Figure  22  60%  Cirrus  Cloud  Layer  Produced  with  the  Interim 

Cloud  Model 
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from  above  and  slightly  off  angle  (similar  to  the  view  one  would  have  looking  out  at  clouds 
below  from  an  airplane  window)  against  a  black  background.  Note  the  straight  edges  vis¬ 
ible  in  the  figures  are  the  edges  of  the  cloud  model  domain. 

We  can  successfully  simulate  visually  realistic  stratiform  clouds  in  the  interim 
model  (as  in  the  first  two  figures).  We  are  also  able  to  produce  non-isotropic  cirriform 
clouds  (Fig.  22).  Currently,  the  prototype  cirriform  model  simulates  only  the  horizontal 
banded/fibrous  nature  of  cirrus.  It  has  no  mechanism  to  treat  the  unique  vertical  structure 
so  often  visible  (e.g.,  falling  cirrus  being  swept  by  the  wind).  In  the  interim  model,  cirri¬ 
form  structure  is  developed  in  the  same  manner  as  stratiform,  by  building  around  the  hori¬ 
zontal  plane.  Future  efforts  will  include  improvements  to  the  cirriform  model. 


2.4  THE  CLOUD  SHADOW  POST  PROCESSOR 

The  presence  of  cloud  shadows  affects  the  energy  budget  at  the  earth’s  surface  by 
modifying  the  heating  and  temperature.  Therefore  cloud  shadows  must  be  considered  in 
surface  energy  computations.  TASC  developed  the  cloud  shadow  post-processor  to  com¬ 
pute  a  shadow  map  for  a  given  ground  domain,  cloud  scene  and  solar  geometry.  A  descrip¬ 
tion  of  the  shadow  post-processor  is  provided  in  this  section. 

The  cloud  shadow  software  package  is  written  in  standard  FORTRAN  77.  The  pack¬ 
age  has  been  tested  on  a  variety  of  Sun  computers,  a  VAX/VMS  6310  and  an  IBM  PC/AT. 
Figure  23  shows  the  relationship  between  the  ground  and  cloud  domains  used  in  the  shad¬ 
ow  post-processor.  The  x-y  center  of  the  cloud  domain  lies  directly  above  the  x-y  center  of 
the  ground  domain.  Typically  the  ground  domain  will  be  smaller  than  the  cloud  domain  so 
that  rays  traced  from  the  ground  to  the  sun  will  pass  through  the  cloud  scene  even  for  low 
solar  angles. 

2.4.1  Mqjor  Procedures 

An  outline  of  the  major  procedures  of  the  cloud  shadow  software  package  follows. 

•  Accept  user  input 

Request  input  parameters  from  the  user  in  a  simple  question 
and  answer  format.  Parameters  include  the  size  and  resolution 
of  the  ground  domain,  name  of  the  input  cloud  scene  and  output 
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Figure  23  Relationship  of  Cloud  and  Ground  Domains  in  the  Cloud  Shadow 
Post-Processor 


shadow  map  files,  and  solar  angles.  The  user  can  specify  the  so¬ 
lar  zenith  and  azimuth  angles  directly  or  give  the  date,  time  and 
location  (which  are  then  used  to  compute  zenith  and  azimuth). 

•  Define  solar  zenith  and  azimuth  angles 

Compute  solar  position  angles  with  respect  to  the  latitude-longi¬ 
tude  position  of  the  ground  domain  for  a  given  date  and  time 
(following  methods  in  Ref.  14).  If  the  user  chooses  to  specify  the 
solar  zenith  and  azimuth  angles  directly,  this  module  is  not  run. 
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•  Track  solar  rays  through  cloud  scene 

Trace  a  path  from  each  gridpoint  in  the  ground  domain,  through 
the  cloud  scene  toward  the  sun.  If  a  cloud  element  (a  non-zero 
water  density  value)  is  found  anywhere  along  the  path  through 
the  cloud  domain,  the  gridpoint  on  the  ground  is  defined  to  be  in 
shadow,  otherwise  it  is  clear. 

•  Write  shadow  map  to  output  file 

Write  the  two-dimensional  binary  shadow  map  to  the  user-speci¬ 
fied  output  file  along  with  a  header  containing  the  size  and  reso¬ 
lution  of  the  ground  domain  and  the  solar  zenith  and  azimuth 
angles. 

2.4.2  Methodology 

The  interim  cloud  model  is  capable  of  generating  cloud  scenes  with  a  maximum  hor¬ 
izontal  extent  on  the  order  of  100  km  by  100  km.  For  cloud  scenes  of  that  size  the  curvature 
of  the  Earth  and  the  cloud  domain  must  be  taken  into  account  when  computing  a  ground 
shadow  map.  Rays  are  traced  from  every  grid  point  in  the  ground  domain  along  a  line  to 
the  sun  through  the  “curved”  cloud  region.  As  each  ray  is  traced  upwards  through  the 
cloud  domain,  the  location  of  the  intersection  of  the  sun  ray  and  the  cloud  domain  is  com¬ 
puted. 

The  point  of  intersection  is  computed  for  each  vertical  level  in  the  cloud  domain  and 
is  then  converted  to  x-y-z  grid  coordinates.  Using  the  direct-access  cloud  scene  file  as  a 
look-up  table,  the  volume  element  corresponding  to  the  computed  x,  y,  z  location  is  re¬ 
trieved.  If  the  liquid  water  density  within  that  volume  element  is  non-zero  (i.e.,  cloud  ex¬ 
ists  at  that  point  in  space),  the  ground  grid  point  is  defined  to  be  in  shadow,  and 
calculations  for  the  succeeding  ground  grid  point  begin.  If  it  is  zero  (i.e.,  no  cloud  exists  at 
that  point),  the  process  continues  to  the  next  vertical  level  in  the  cloud  scene.  The  process 
ends  when  a  cloud  element  is  found  or  when  all  vertical  levels  in  every  possible  cloud  layer 
have  been  traversed. 

The  x-y  intersection  point,  computed  for  each  vertical  level  in  the  cloud,  is  defined  in 
terms  of  x  and  y  offsets  measured  from  the  center  of  the  cloud  domain.  Two  components 
make  up  each  of  the  x  and  y  offsets.  The  first  components  (Sxo  and  Syo)  depend  on  the  posi¬ 
tion  of  the  ground  grid  point  as  measured  from  the  center  of  the  ground  domain.  The  sec¬ 
ond  components  (Sxi  and  Syi)  take  into  account  the  angle  that  the  sun  rays  make  with 
respect  to  the  ground  domain.  The  total  offset  in  each  direction  is  the  sum  of  the  two  compo¬ 
nents  (see  Fig.  24  for  reference). 
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Figure  24  X-Z  Cross-Section  Showing  Variables  Used  in  Cloud 
Shadow  Calculations 

Before  computing  the  offsets  in  the  two  coordinate  directions,  the  solar  azimuth  and 
zenith  angles  (0a  and  0*.  respectively)  must  be  reduced  to  Cartesian  coordinates  (0X  and 
0  y),  where  0  x  and  0  y  are  the  angular  distance  from  zenith  in  the  x  and  y  directions,  respec¬ 
tively  (Fig.  25).  The  angles,  0  x  and  0  y,  can  be  computed  by  the  following  simple  geometric 
relationships. 


Figure  25  Geometry  Used  to  Convert  Solar  Angles  to  Cartesian  Coordinates 


TAN  0Z  =  r/z  (2.4-1) 

x  =  rSIN0a  =  =  >  x  =  z(TAN0z)(SIN0a)  (2.4-2) 

y  =  rCOS0a  =  =  >  y  =  z(TAN0z)(COS0a)  (2.4-3) 

0X  =  ARCTAN(x/z)  =  =  >  0X  =  ARCTAN  j(TAN6z)  (SIN0a)]  (2.4-4) 
0y  =  ARCTAN(y/z)  =  =  >  0y  =  ARCTAN  [(TAN0z)  (COS0a)]  (2.4-5) 


A  description  of  each  of  the  two  components  which  make  up  the  total  x  and  y  offsets 
follows  below.  First,  the  offset  due  to  the  position  of  the  ground  grid  point  (Sxo)  is  computed 
in  the  x-direction  as  follows  (see  Fig.  24): 
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where 


Re  =  radius  of  the  earth 

x  =  distance  of  the  gridpoint  from  the  center  of  the  ground  domain  in  the 
x-direction 

z  =  height  of  a  level  in  the  cloud  domain. 

The  y  offset  (Syo)  is  computed  in  the  same  manner.  The  point  corresponding  to  these  offsets 
is  the  point  that  would  be  traversed  if  the  sun  was  directly  overhead.  For  cases  in  which  the 
sun  is  not  directly  overhead  a  second  contribution  to  the  x  and  y  offsets  must  be  computed 
(Sxi  and  Syi).  Using  the  law  of  sines  and  some  simple  geometry,  the  offset  due  to  solar  angle 
effects  can  be  found  as  follows  (we  have  outlined  the  calculations  in  the  x-direction,  similar 
results  are  found  in  the  y-direction): 
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A  multiplication  factor  based  on  the  location  of  the  sun  is  added  to  keep  track  of  the  sign  of 
the  offset.  The  total  offsets  due  to  both  ground  position  and  solar  angle  in  each  direction 
are: 

^xtotal  =  ^xO  +  Sxl  (2.4-13) 

Sytotal  =  SyO  +  Sy  1 .  (2.4-14) 

As  previously  noted,  the  offsets  from  the  midpoint  of  the  cloud  domain  at  each  level 
are  converted  to  grid  coordinator.  The  coordinates  define  an  index  into  the  direct-access 
file  containing  the  multi-layer  cloud  scene.  There  are  no  limits  to  the  resolution  of  the 
ground  domain,  except  for  limits  on  overall  computational  resources.  In  practice  however, 
effective  resolution  on  the  ground  is  limited  by  the  resolution  of  the  cloud  scene. 
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2.5  THE  VISUALIZATION  POST  PROCESSOR 


In  support  of  the  Engineer  Topographic  Laboratories  as  a  SWOE  demonstration 
participant,  we  developed  the  visualization  post-processor  to  convert  cloud  model  output 
fields  (generated  with  the  interim  model)  to  a  form  acceptable  for  use  in  the  Computer 
Image  Generation  (CIG)  system  at  ETL.  The  cloud  scenes  generated  with  the  interim 
cloud  model  are  stored  as  three-dimensional  arrays.  ETL  required  that  these  arrays  be 
converted  to  polygonally  faceted  surface  representations  for  use  with  their  CIG  system. 
We  use  the  marching  cubes  algorithm  to  perform  this  conversation  (Ref.  15). 

The  marching  cubes  algorithm  finds  an  approximate  isosurface  for  the  3-d  cloud 
data.  The  surface  is  specified  as  a  list  of  triangles;  each  triangle  is  defined  by  a  set  of  in¬ 
dices  into  a  vertex  list.  The  vertex  list  contains  the  spatial  position  of  each  vertex  along 
with  color  information  (i.e.,  grey-scale  color)  based  on  position  with  respect  to  the  sun  and 
attenuation  effects  for  that  vertex.  We  discuss  the  marching  cubes  algorithm  in  Sec¬ 
tion  2.5.1.  In  Section  2.5.2  we  describe  the  technique  employed  to  color  each  vertex. 

2.5.1  The  Marching  Cubes  Algorithm 

The  marching  cubes  algorithm  was  developed  for  computed  tomography  (CTSCAN) 
data  sets,  which  are  composed  of  a  three-dimensional  volume  of  density  samples.  The  algo¬ 
rithm  steps,  or  “marches,”  through  the  data  set  one  slice  at  a  time,  comparing  eight  density 
samples  (i.e.  the  comers  of  a  cube)  against  a  user-specified  threshold  value.  Each  sample  is 
classified  as  a  “1”  or  “0”  based  on  whether  the  density  at  that  point  falls  above  or  below  the 
threshold,  respectively.  (Samples  with  density  equal  to  the  threshold  are  also  classified  as 
“1”).  The  eight  samples  composing  each  cube  (when  classified  as  “0”  or  ”1”)  define  an  8  bit 
integer  which  is  used  as  an  index  into  a  look-up  table  of  precalculated  polygonal  facets  for  a 
cube  (Fig.  26).  There  are  256  configurations  of  polygonal  facets,  which,  when  symmetry  is 
accounted  for,  reduce  to  the  15  cases  shown  in  Fig.  27. 

The  look-up  table  specifies  each  polygonal  facet  in  a  given  index  location  as  a  list  of 
edge  indices.  These  edge  indices  correspond  to  the  edges  along  which  each  vertex  lies.  The 
location  of  the  vertex  upon  the  edge  is  calculated  via  a  direct  linear  interpolation  between 
the  two  surrounding  corners.  This  linear  interpolation  utilizes  the  density  values  at  each 
corner  as  weighting  factors. 

The  voxel  data  set  is  specified  in  an  integer  coordinate  system  based  upon  the  num¬ 
ber  of  samples  in  each  of  the  x,  y  and  z  dimensions.  As  the  algorithm  marches  through  the 
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Figure  26  Index  Look-Up  Table  with  Vertex  Geometry  Displayed  for 
Reference  (From  Ref.  15) 

data  set  it  forms  the  cubes  it  processes  from  the  samples  found  in  two  adjacent  slices  of 
data.  Each  edge  from  which  the  actual  polygon  vertex  values  are  interpolated  will  be 
shared  by  up  to  four  adjacent  cubes.  It  is  therefore  possible  to  reduce  the  amount  of  work 
the  algorithm  performs  by  using  a  hash  table  storage  technique.  Each  sample  point,  speci¬ 
fied  in  its  [i  j,k]  integer  coordinate  space,  can  be  thought  to  have  three  edges  connected  to 
it,  one  in  each  of  the  x,  y  and  z  directions.  By  storing  the  [x,y,z]  value  of  the  polygon  vertex 
calculated  on  a  given  edge  in  a  sequential  list,  the  index  of  that  vertex  can  subsequently  be 
stored  in  a  hash  table  at  a  location  calculated  from  the  [i  j,k]  coordinate  of  the  associated 
sample  point.  The  linear  interpolation  need  not  be  performed  again,  the  vertex  index  can 
simply  be  retrieved  via  a  hash  table  look-up. 

In  addition  to  this  efficiency  improvement,  certain  additional  calculations  must  be 
performed  to  account  for  anomalies  in  the  data  sets.  The  marching  cubes  algorithm  as¬ 
sumes  that  slices  are  oriented  so  that  no  surface  will  lie  directly  upon  the  face  of  the  cubes 
it  builds  from  these  slices.  In  our  data  sets  this  may  not  be  the  case.  If  the  surface  does  lie 
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along  the  face  of  the  cube,  additional  polygons  must  be  created  along  the  face  to  insure  sur¬ 
face  closure.  In  the  application  of  the  marching  cubes  algorithm  to  cloud  fields,  we  test  for 
closure  along  the  top  and  bottom  vertical  slices.  First  we  find  an  average  density  value  for 
the  flat  faces.  Then,  if  the  average  value  exceeds  the  specified  threshold,  additional  poly¬ 
gons  are  specified  using  vertices  already  calculated  for  the  configuration  in  question. 

We  have  found  that,  in  general,  hundreds  of  thousands  of  polygons  are  required  to 
approximate  the  complex  cloud  surfaces  generated  with  the  interim  model.  The  CIG  sys¬ 
tem  is  limited  to  approximately  30,000  polygons  for  any  one  geometry  model.  We  can  solve 
this  problem  by  breaking  the  cloud  domain  into  smaller  pieces,  each  of  which  fits  within 
the  ETL  polygon  limit.  Each  portion  can  then  be  rendered  independently. 

2.5.2  Assigning  Colors  To  Cloud  Surfaces 

The  normal  to  the  surface  at  each  vertex  is  used  to  determine  the  color  at  the  vertex. 
We  compute  the  normal  at  each  voxel  in  a  pre-processing  step  by  calculating  the  three-di¬ 
mensional  gradient  of  cloud  water  density  at  the  voxel.  When  interpolation  is  performed  to 
calculate  the  vertex  locations,  the  gradient,  also  linearly  interpolated,  is  calculated  too. 
The  unit  surface  normal  at  the  vertex  is  simply  the  interpolated  gradient  divided  by  its 
magnitude. 

After  all  vertices  and  polygons  have  been  determined,  an  additional  processing  step 
is  performed.  First  a  base  color  for  the  vertices  is  specified  by  the  user  or  set  equal  to  a  de¬ 
fault  value.  Sun  position  is  also  determined  from  user  input.  The  list  of  vertices  is  then  tra¬ 
versed.  For  every  vertex,  the  (x,y,z)  position  is  retrieved  and  the  associated  (i  j,k)  voxel  is 
determined.  From  the  position  of  the  vertex  and  the  position  of  the  light  source  we  calcu¬ 
late  a  light  direction  vector.  Using  this  direction  vector  all  voxels  that  lie  between  the  cur¬ 
rent  vertex  and  the  light  source  are  determined,  and  their  liquid  water  density  values  are 
summed.  If  this  sum  is  zero,  then  the  vertex  lies  on  a  side  of  the  cloud  facing  the  light 
source,  otherwise  it  does  not.  Figure  28  gives  a  graphical  example  of  three  vertex  loca¬ 
tions,  their  direction  vectors  and  integrated  path  lengths  through  the  cloud. 

Color  at  each  vertex  is  calculated  as  the  default  base  color  (generally  bright  white) 
less  a  certain  amount  of  “darkening.”  Darkening  is  due  to  two  effects:  1)  surface  normal 
shading  and  2 )  attenuation  within  the  cloud.  Surface  normal  shading  is  a  function  of  L*  fT 
where  L  is  the  light  source  vector  and  N  is  the  surface  normal  vector  (Ref.  16).  For 
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Figure  28  Direction  Vectors  from  Three  Sample  Vertices  Through  the  Cloud 
Toward  the  Sun.  Integrated  Liquid  Water  Content  Along  each 
Vector  is  used  in  Color  Computations 


vertices  that  lie  on  a  polygon  which  faces  the  light  source  (i.e.,  no  cloud  elements  are  be¬ 
tween  it  and  the  light  source),  the  amount  of  darkening  is  based  on  surface  normal  shad¬ 
ing.  Otherwise,  darkening  is  based  on  the  density  sum.  Cloud  size,  average  voxel  density 
and  maximum  voxel  density  are  used  to  compute  a  “normalization  factor.”  The  integrated 
density  along  a  vector  from  the  vertex  point  to  the  light  source  is  divided  by  the  normaliza¬ 
tion  factor  to  determine  a  percentage.  The  base  color  is  then  darkened  by  that  percentage. 

All  vertices  either  face  the  light  source  or  are  obscured  by  some  portion  of  the  cloud. 
For  vertices  that  are  blocked  by  thin  portions  of  the  cloud  the  darkening  is  very  slight  and 
the  color  is  relatively  bright.  For  vertices  that  are  on  the  farthest  side  of  the  cloud  from  the 
light  source  the  darkening  is  greater.  This  technique  results  in  very  realistic  cloud  coloring 
as  can  be  seen  in  Fig.  29  which  shows  a  view  from  the  ground  looking  up  toward  a  cloud 
base.  All  of  the  grey-scale  variations  in  this  figure  are  due  to  attenuation  through  the  up¬ 
per  portions  of  the  cloud. 


I'igure  29  :  IL-Lav  a  90';  Stratocumulus  Laver  <  10  x  10  km 

; 1  •  -  I  >oniriin  •  Showing  t ho  Effects  of  Polygon  Coloring 

•  •  >■  iar  Azimuth  and  Zenith  Angles  Equal  to  45" 
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STATISTICAL  ANALYSIS  OF  CLOUD  DATA 


One  important  aspect  of  the  Studies  and  Analyses  task  is  the  comparison  of  model- 
produced  and  observed  liquid  water  density  statistics.  With  sufficient  observational  data 
we  can  use  maximum  likelihood  (and  other)  techniques  to  estimate  model  parameter  val¬ 
ues,  evaluate  the  significance  of  the  estimates,  and  (most  importantly)  evaluate  the  appro¬ 
priateness  of  the  SRA,  BSW  (and  later,  turning  bands)  models. 

In  this  section  we  describe  the  SWOE  demonstration  locations  for  which  environ¬ 
mental  conditions  will  be  simulated.  We  discuss  the  database  of  aircraft  measurements 
available  from  the  FAA  for  the  surrounding  regions,  and  describe  the  criteria  used  to  select 
LWC  series  for  use  in  parameter  calibration.  We  present  profiles  of  the  aggregate  cloud 
data  as  well  as  for  individual  cloud  types.  Finally  we  show  results  of  a  preliminary  compar¬ 
ison  of  model-produced  LWC  series  and  measurements  for  two  cloud  types. 


3.1  CLOUD  MODEL  DEMONSTRATION  SITES 

The  cloud  model  is  expected  to  simulate  various  cloud  conditions  at  any  location. 
The  current  SWOE  demonstration  location  is  Hunter-Liggett,  California.  Hunter-Liggett 
is  located  along  the  California  coast,  between  Monterey  and  San  Luis  Obispo.  This  desert¬ 
like  area  is  bounded  on  the  north  by  the  Coast  Mountain  Range  and  on  the  south  and  the 
west  by  the  Santa  Lucia  Range.  The  area  is  dry  during  the  summer  with  some  rain  in  the 
winter.  There  is  some  marine  influence  along  the  western  front  due  to  the  lower  elevation 
of  the  Santa  Lucia  Range.  These  conditions  also  exist  in  areas  such  as  southern  France, 
southwest  coast  of  South  Africa  and  some  other  locatic  is  in  California.  One  location  which 
approximates  this  climatology,  and  for  which  there  are  extensive  data  available,  is  the 
Sacramento  area  which  includes  Auburn,  Blue  Canyon  and  Lake  Tahoe.  Auburn  is  located 
to  the  north  of  Sacramento,  and  Blue  Canyon  and  Lake  Tahoe  are  to  the  northeast.  Auburn 
best  approximates  the  Hunter-Liggett  area,  followed  by  Blue  Canyon  and  Lake  Tahoe. 
The  latter  two  areas  are  higher  in  elevation  with  respect  to  Auburn.  Lake  Tahoe  has  the 
highest  elevation  and  close  to  alpine  climate  conditions. 
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3.2  FAA  DATABASE  DESCRIPTION 


Based  on  our  survey,  the  FAA  cloud  database  (formerly  with  the  Naval  Research 
Laboratory)  is  the  most  comprehensive  and  is  reputed  to  be  the  best  in  the  US.  The  data, 
originally  obtained  from  various  sources  (digital  tapes,  tabular  reports  and  journal  ar¬ 
ticles),  have  been  condensed  in  a  standardized  format.  The  database  consists  of  time  series 
of  a  variety  of  cloud-related  variables  along  with  averaged  cloud  data  based  on  those  series 
(described  below).  By  analyzing  the  averaged  variables,  we  were  able  to  select  a  group  of 
series  to  use  in  our  comparison  with  model-produced  LWC  data. 

The  principal  variables  in  the  FAA  database  give  information  about  the  mission 
flight,  cloud  systems,  prevailing  weather  and  measurement  related  factors.  Mission  iden¬ 
tifier  variables  include  date,  time,  measuring  agency,  geographical  location  and  surface 
elevation.  Cloud  information  variables  include  cloud  type,  cloud  group,  cloud  identifica¬ 
tion  number,  prevailing  cloud  distribution,  cloud  base  and  top  heights  and  temperatures  of 
cloud  base  and  top.  Weather  variables  include  air  mass  information  and  coded  descrip¬ 
tions  of  the  weather  conditions  associated  with  the  clouds  under  study.  Measurement-re¬ 
lated  variables  include  the  time  duration  (seconds)  of  the  data  sample,  the  distance  (nmi) 
travelled  by  the  aircraft,  aircraft  flight  path  (i.e.,  level,  slant,  spiral)  during  the  sample, 
the  type  and  intensity  of  precipitation,  if  any,  observed  at  flight  level  from  the  aircraft  or  on 
the  ground  below  the  cloud  under  study  and  the  state  of  the  cloud  particles  sampled  (water 
droplets,  ice  particles  or  both).  The  database  also  contains  averaged  variables  such  as  air¬ 
speed  (knots),  altitude  (feet),  air  temperature  (deg  C),  LWC  (g/m3)  indicated  by  a  hot-wire 
meter  (Johnson-Williams  or  CSIRO-King),  LWC  computed  from  the  droplet  size  distribu¬ 
tion  indicated  by  the  FSSP  (Forward  Scattering  Spectrometer  Probe),  median  volume 
diameter  (um)  computed  from  FSSP  droplet  size  distribution,  droplet  number  density 
(no/cm3)  indicated  by  the  FSSP  and  particle  number  density  (no/liter)  indicated  by  ice 
particle  counters.  The  average  LWC  (ALWC)  is  the  average  of  the  measured  and  computed 
LWC  (from  the  meter  and  the  probe,  respectively).  Further  information  about  the 
Johnson-Williams  meter  and  the  FSSP  are  given  in  Ref  17. 

Each  variable  is  averaged  over  continuous,  uniform  portions  of  the  clouds.  A  set  of 
rules  has  been  established  to  define  uniform  cloud  intervals.  The  rules  are  based  on 
changes  in  air  temperature,  median  droplet  diameter,  aircraft  altitude,  icing  rate,  droplet 
number  density  and  the  effect  of  snow  or  ice  particles  on  the  FSSP.  The  averaging  interval 
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is  described  as  follows.  If  the  aircraft  is  still  in  continuous  clouds  at  the  end  of  the  averag¬ 
ing  interval,  a  new  averaging  interval  is  immediately  started  and  continued  until  the  next 
significant  change  in  cloud  properties  occurs.  Otherwise,  the  next  interval  begins  when 
the  aircraft  enters  another  continuous  cloud  area.  The  advantages  of  this  averaging 
scheme  are  listed  below. 

•  Fixed  intervals,  e.g.,  one  minute  averages  or  averages  over  entire  cloud 
passes  are  avoided. 

•  Averaging  intervals  are  short  enough  to  resolve  any  significant  changes 
in  cloud  characteristics  along  the  flight  path. 

•  Averages  remove  extremes  of  particle  mass  concentrations  or  other  vari¬ 
ables. 

•  Averages  preserve  altitude  dependent  changes  in  cloud  properties  ob¬ 
served  during  ascents  or  descents  through  clouds. 

•  Broken  or  scattered  cloud  conditions  as  well  as  widespread  continuous 
clouds  are  accommodated. 

•  Horizontal  extent  of  continuous  or  semi-continuous  icing  conditions  is 
available  by  summing  the  extents  of  consecutive  averaging  intervals. 


3.3  SPATIAL  SERIES  DATA  SELECTION 

To  facilitate  the  selection  of  spatial  series  data  sets,  a  preliminary  statistical  profile 
of  the  California  data  was  taken.  The  measurements  were  taken  over  the  Sacramento  area 
during  the  winter  months  in  the  years  1979-80, 1982-83  in  conjunction  with  an  icing  mea¬ 
surement  program.  The  six  cloud  types  include  non-orographic  stratus  (St),  stratocumu- 
lus  (Sc),  cumulus  (Cu),  and  towering  cumulus  (Tc),  and  orographic  cumulus  (Orcu)  and 
stratocumulus  (Orsc).  The  statistical  analyses  used  in  data  selection  included: 

•  histograms  of  sample  duration,  altitude,  ALWC  and  distance 

•  3-d  bar  plots  of  cloud  base  and  top  heights  and  ALWC 

•  scatter  plots  of  altitude  and  ALWC. 

Figure  30  shows  the  California  data  profile  which  includes  all  six  cloud  types.  Duration  is 
in  units  of  seconds,  distance  in  nautical  miles,  altitude  in  100’s  of  feet,  ALWC  is  given 
in  g/m3  and  count  is  the  sample  frequency  of  occurrence.  To  better  accommodate  the  dy¬ 
namic  range  of  the  plotting  routine  used  to  generate  Fig.  30,  we  transformed  cloud  base 
and  top  heights  and  ALWC  by  the  following: 
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Data  Profile  of  All  Cloud  Types  Measured  in  Northeastern  California  During  February  to 
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These  transformation  equations  allow  the  3-d  bar  plots  to  be  viewed  from  the  higher  val¬ 
ued  interval  (lower  frequency  of  occurrence)  to  lower  valued  interval  (higher  frequency  of 
occurrence).  In  most  cases,  this  scheme  provides  a  clear  line  of  sight  of  most  of  the  data  in 
the  plot.  Ambiguities  are  clarified  in  the  individual  3-d  bar  plots  that  follow  in  Figs.  31 
through  36. 

As  shown  in  Fig.  30,  most  of  the  series  are  of  relatively  short  duration  (on  the  order 
of  seconds).  The  distance  travelled  by  the  aircraft  in  these  cases  varies  from  about  0.15  nmi 
to  2.4  nmi,  although  there  are  a  few  cases  in  which  the  distance  travelled  is  relatively  long 
(7  nmi  - 18  nmi).  Most  cloud  altitudes  fall  between  6,700  ft  to  13,000  ft.  Because  there  is  no 
information  on  the  top  height  for  cumulus,  only  five  cloud  types  (of  the  six  mentioned 
above)  are  represented  in  the  3-d  bar  plot.  The  cloud  ALWC  values  vary  from  0.0  - 1.67  (g/ 
m3);  the  lower  ALWC  values  occur  more  frequently.  The  Cu  and  Orcu  cloud  types  have  a 
more  even  distribution  of  ALWC.  Figures  31  to  36  present  the  data  profiles  for  each  cloud 
type.  These  figures  are  useful  during  comparative  analyses. 

The  criteria  for  spatial  series  data  selection  are  as  follows: 

•  different  cloud  types 

•  long  sample  duration 

•  cloud  ALWC  variations 

•  cloud  altitude  variations 

•  aircraft  level  maneuver. 

For  each  cloud  type,  scatter  plots  of  ALWC  and  altitude  versus  duration  were  made.  Based 
on  these  scatterplots,  we  selected  a  number  of  spatial  series  that  best  met  the  criteria 
listed  above.  Scatter  plots  for  Orcu  are  shown  in  Fig.  37  where  we  have  highlighted  the 
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series  that  were  selected.  The  overriding  criterion  for  selection  is  long  sample  duration. 
Among  the  long  duration  data  sets,  we  chose  series  with  level  flight  paths  and  varying 
ALWC  and  altitude.  With  the  aid  of  scatter  plots  similar  to  Fig.  37  for  each  of  the  cloud 
types,  twenty  two  data  sets  (at  least  three  for  each  cloud  type)  were  ordered  from  the  FAA. 
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Figure  37  Sample  Scatter  Plots  Used  in  Data  Selection  Process  (This  Example 
For  Orcu  Cloud  Type).  Datasets  with  Longest  Duration  at  Various 
ALWC  and  Altitude  Values  were  Selected 
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3.4  COMPARISON  OF  ONE-DIMENSIONAL  SPATIAL  SERIES 


In  this  section  we  present  results  of  our  comparison  of  observed  and  synthetic  cloud 
water  data  using  standard  time  series  analysis  tools.  We  have  limited  our  initial  analysis 
to  St  and  Orsc  (corresponding  to  Sc  in  the  interim  model)  cloud  types.  For  the  comparison, 
we  simulated  cloud  fields  having  the  same  physical  characteristics  (top  and  base  heights, 
spatial  resolution,  etc.)  and  extracted  horizontal  (i.e.,  level  paths)  from  various  locations  in 
the  output  field.  Figure  38  shows  observed  LWC  series  side  by  side  with  corresponding 
modeled  series  (generated  with  the  SRA  model)  for  both  St  and  Orsc  cloud  types.  Qualita¬ 
tively,  the  modeled  and  measured  series  are  very  similar.  (One  should  note  that  the  large 
visual  difference  between  the  two  cloud  types  is  partly  due  to  the  difference  in  series 
length.  The  Orsc  series  is  almost  4  times  the  length  of  the  St  series.) 

In  the  example  in  Fig.  38  we  have  chosen  the  mean  and  standard  deviation  of  the 
modeled  LWC  to  correspond  to  the  exact  observed  statistics.  We  calculate  the  Hurst  pa¬ 
rameter  from  the  observed  series  using  the  box-dimension  algorithm  (Ref.  3)  which  esti¬ 
mates  the  fractal  dimension  of  the  series.  Estimates  for  the  lacunarity  parameter  are 
based  on  trial  and  error.  The  curves  shown  in  Fig.  38  are  typical  of  the  numerous  series  we 
have  studied  to  date. 

A  key  tool  in  our  analysis  (specifically  for  the  estimation  of  the  lacunarity  parame¬ 
ter)  is  the  autocorrelation  function  (ACF).  The  sample  ACF  is  defined  as 

N 

ACF(lag)  =  ^  (lwct  -  <  lwc  >)  (lwct_lag  -  <  lwc  >) 

t  =  lag  +  1 

where 


o2  =  variance  in  the  sample  data 
N  =  number  of  data  points  in  the  series 
<lwc>  =  mean  liquid  water  content 

t  =  time  (space)  index. 

In  Fig.  39  we  include  the  empirical  and  model  autocorrelation  functions  corresponding  to 
the  series  in  Fig.  38.  Again  we  see  very  good  qualitative  agreement  (typical  of  the  numer¬ 
ous  series  we  looked  at)  between  the  measured  and  modeled  functions. 
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Figure  38  Observed  (using  FSSP)  and  Corresponding  Modeled  LWC  Spatial  Series  for  Orsc  and  St  Cloud  Types 


Due  to  the  short  length  of  many  of  the  observed  series,  and  the  small  overall  number 
of  available  series,  our  conclusions  are  only  qualitative;  the  SRA  model  (with  suitable  pa¬ 
rameters)  can  be  used  to  simulate  clouds  with  horizontal  variability  and  correlation  struc¬ 
ture  characteristic  of  the  measured  lwc  data  sets.  Ideally  we  would  like  to  continue  this 
analysis  to  test  for  the  suitability  of  the  SRA  algorithm  to  model  the  vertical  variations  in 
LWC.  The  very  limited  number  and  overall  duration  of  the  slant  path  data  sets  make  this 
analysis  impossible  at  the  current  time.  We  are  confident  however,  that  we  can  model  vari¬ 
ations  in  the  mean  LWC  as  a  function  of  height  following  Feddes’  model  (Ref.  7). 
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4. 


SUMMARY  AND  FUTURE  PLANS 


4.1  SUMMARY 

The  interim  cloud  scene  simulation  model,  developed  under  the  BTI/SWOE  pro¬ 
gram,  is  an  efficient  and  portable  tool  to  generate  multi-layer  cloud  scenes  containing  cir- 
riform  and  stratiform  cloud  types  (cumuliform  will  be  included  in  the  enhanced  model). 
Cloud  scenes  consist  of  a  3-d  field  of  LWC  values,  and  may  be  used  as  input  to  other  SWOE 
models  such  as  those  for  thermal  and  radiative  transfer.  Development  of  the  enhanced 
cloud  model  is  currently  underway  and  will  include  additional  capabilities  as  discussed 
below  in  Section  4.2. 

In  this  report  we  have  described  the  design  and  development  of  the  cloud  scene  sim¬ 
ulation  model.  We  have  outlined  the  major  model  processes,  including  a  description  of  the 
SRA  fractal  algorithm  which  is  the  basis  of  the  model .  We  have  also  shown  results  of  a  com¬ 
parison  of  model  data  and  actual  LWC  measurements.  Though  more  analysis  is  desired, 
early  results  are  promising,  showing  ve;y  good  qualitative  agreement  between  spatial  se¬ 
ries  extracted  from  several  datasets.  We  conclude,  in  the  following  sections,  with  a  discus¬ 
sion  of  plans  for  future  work  both  in  model  development  and  evaluation. 


4.2  THE  ENHANCED  MODEL  (VERSION  3.0) 

The  prototype  and  interim  models  were  designed  specifically  to  provide  a  platform 
for  algorithm  testing  and  development,  and  to  encourage  feedback  early  in  the  project 
from  others  in  the  SWOE  community.  Both  models  include  the  most  fundamental  func¬ 
tions  of  the  cloud  model:  to  generate  the  horizontal  distribution  of  cloud  elements,  their 
vertical  structure  and  their  internal  LWC  distributions.  Over  the  development  period  we 
identified  both  strengths  and  weaknesses  in  the  model  and  its  algorithms  and  we  have 
changed  the  design  accordingly.  The  enhanced  model  will  include  all  of  the  fundamental 
functions  of  the  two  previous  versions  (suitably  modified)  along  with  a  number  of  addition¬ 
al  capabilities. 

Three  additional  capabilities  are  currently  being  implemented:  a  cumuliform  cloud 
model,  temporal  evolution,  and  a  variable  resolution  grid.  The  cumuliform  model  will  be 
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based  in  part  on  convection  physics.  The  evolution  capability  will  feature  both  advection  of 
clouds  by  layer  average  winds  and  stochastic  evolution  (growth,  change  and  decay)  of 
cloud  elements.  Differential  advection  of  adjacent  layers  will  permit  and  accommodate 
vertical  wind  shears.  Stochastic  evolution  will  be  achieved  by  adding  a  fourth  (temporal) 
dimension  to  the  SRA  algorithm.  The  other  new  design  feature,  non-uniform  grid  resolu¬ 
tion,  will  provide  the  maximum  resolution  where  it  is  needed  most,  in  the  vicinity  of  the 
sensor.  Near  the  horizon  the  resolution  will  be  lower. 


4.3  EVALUATION  OF  FIELD  ALGORITHMS 

Throughout  the  course  of  model  development  we  have  evaluated  and  compared  the 
SRA  and  BSW  algorithms  in  their  ability  to  model  realistic  3-d  LWC  perturbation  fields. 
Up  to  this  point,  our  evaluations  have  been  mainly  qualitative,  comparing  the  visual  ap¬ 
pearance  of  the  fields  and  checking  for  the  presence  of  artifacts. 

We  are  also  concerned  with  the  flexibility  of  each  algorithm  to  produce  fields  that 
are  representative  of  a  variety  of  cloud  types.  The  Hurst  and  lacunarity  parameters  pro¬ 
vide  that  flexibility  in  the  SRA  algorithm.  Wavelength  parameters  control  similar  func¬ 
tions  in  the  BSW,  though  we  are  limited  to  short  wavelengths  to  avoid  discontinuities  and 
artifacts  (see  Section  2.2.3). 

Future  work  will  involve  evaluating  the  turning  bands  algorithm  with  the  same 
qualitative  measures  we  have  used  with  the  SRA  and  BSW  algorithms:  field  quality  and 
algorithm  flexibility.  We  will  also  evaluate  the  field  algorithms  based  on  more  quantitative 
measures  such  as  computational  speed  and  memory  requirements.  Finally,  we  will  com¬ 
pare  LWC  series  produced  with  each  of  the  algorithms  to  the  LWC  measurement  data  (part 
of  Task  3). 


4.4  INTEGRATION  WITH  OTHER  SWOE  MODELS 

The  cloud  scene  simulation  model  is  one  of  many  models  that  will  be  used  in  the  BTI/ 
SWOE  sensor  evaluation  program.  Cloud  model  output  fields  will  be  used  in  both  thermal 
and  radiative  transfer  models  developed  independently.  It  is  crucial  that  these  varied 
models  are  compatible  so  that,  for  example,  output  from  one  model  is  of  the  correct  type 
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and  format  to  use  as  input  to  another.  Task  5  deals  explicitly  with  the  question  of  SWOE 
compatibility  and  integration  and  is  an  important  aspect  of  the  modeling  project. 

Throughout  model  development  we  have  carefully  designed  the  cloud  model  around 
those  specifications  gathered  early  in  the  project  during  the  requirements  and  analysis 
task  (Task  1).  When  necessary,  and  in  the  absence  of  opinions  from  other  SWOE  users  and 
modelers,  we  have  made  conservative  design  decisions,  always  keeping  in  mind  the  goal  of 
developing  a  low-maintenance,  modular  model.  In  the  upcoming  months,  as  a  part  of  Task 
5,  we  will  continue  to  solicit  feedback  from  the  SWOE  community  (especially  in  regard  to 
the  thermal  and  radiative  transfer  models)  as  we  develop  the  enhanced  cloud  model. 
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